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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



Voice call continuity allows users to move between the CS domain and the IP Connectivity Access Network (e.g., 
WLAN interworking) with home IM CN subsystem functionality. 

The present document provides the protocol details for voice call continuity between the IP Multimedia (IM) Core 
Network (CN) subsystem based on the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP) and 
the protocols of the 3GPP Circuit-Switched (CS) domain (CAP, MAP, ISUP, BICC and the NAS call control protocol 
for the CS access). 

This document makes no VCC specific enhancements to SIP, SIP events or SDP, beyond those specified in 

3GPPTS 24.229 [7]. 

The present document is applicable to User Equipment (UEs), Application Servers (AS) and Media Gateway Control 
Functions (MGCF) providing voice call continuity capabilities. 



References 



The following documents contain provisions which, through reference in this text, constitute provisions of the present 
document. 

• References are either specific (identified by date of publication, edition number, version number, etc.) or 
non-specific. 

• For a specific reference, subsequent revisions do not apply. 

• For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including 
a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same 
Release as the present document. 

[I] 3GPP TS 22.101: "Service aspects; Service principles". 

[2] 3GPP TS 23.003: "Numbering, addressing and identification". 

[3] 3GPP TS 23.206: "Voice call continuity between Circuit Switched (CS) and IP Multimedia 

Subsystem (IMS); Stage 2". 

[4] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". 

[5] 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". 

[5 A] 3GPP TS 24.084: "MultiParty (MPTY) Supplementary Service; Stage 3". 

[6] 3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3". 

[6A] 3GPP TS 24.173: "IMS Multimedia telephony service and supplementary services; Stage 3". 

[6B] 3GPP TS 24.216: 'Communication Continuity Management Object (MO)' 

[7] 3GPP TS 24.228 Release 5: "Signalling flows for the IP multimedia call control based on Session 

Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3". 

[8] 3GPP TS 24.229: "IP Multimedia Call Control Protocol based on SIP and SDP". 

[9] 3GPP TS 29.078: "Customised Apphcations for Mobile network Enhanced Logic (CAMEL) Phase 

4; CAMEL Application Part (CAP) specification". 

[10] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem 

and Circuit Switched (CS) networks". 

[II] 3GPP TS 29.328: "IP Multimedia Subsystem (IMS) Sh interface; Signalhng flows and message 
contents". 
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[12] 3GPP TS 29.329: "Sh interface based on the Diameter protocol; Protocol details". 

[13] ITU-T Recommendation E. 164: "The international public telecommunication numbering plan". 

[14] ITU-T Recommendations Q.761to Q.764 (2000): "Specifications of Signalhng System No.7 ISDN 

User Part (ISUP)". 

[15] ITU-T Recommendations Q.1902.1 to Q.1902.6 (07/2001): "Bearer Independent Call Control". 

[16] Void 

3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply. 

Retarget: A SIP request is retargeted when the original "target" indicated by the Request-URI is changed to 

a new "target" by changing the Request-URI. 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [4] 
subclauses 5.4.12 apply: 

Public Service Identity (PSI) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.003 [2] apply: 

CS Domain Routeing Number (CSRN) 
IP Multimedia Routeing Number (IMRN) 
Mobile Station Roaming Number (MSRN) 
VCC Domain Transfer Number (VDN) 
VCC Domain Transfer URI (VDI) 

For the purposes of the present document, the following terms and definitions given in ITU-T E.164 [13] apply: 

International public telecommunication number 
Public telecommunications number 

For the purpose of the present document, the following terms and definitions given in 3GPP TS 23.206 [3] apply: 

VCC application 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AS Application Server 

BICC Bearer Independent Call Control 

CAMEL Customised Applications for Mobile network Enhanced Logic 

CAP CAMEL Application Part 

CCCF Call Continuity Control Function 

CN Core Network 

CS Circuit Switched 

CSAF CS Adaptation Function 

CSCF Call Session Control Function 

CSRN CS Domain Routeing Number 

DSF Domain Selection Function 

DTF Domain Transfer Function 

EDGE Enhanced Data rates for GSM Evolution 

GERAN GSM EDGE Radio Access Network 

GMSC Gateway MSC 
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GSM Global System for Mobile communications 

HLR Home Location Register 

HSS Home Subscriber Server 

IM IP Multimedia 

IP Internet Protocol 

IMRN IP Multimedia Routeing Number 

ISDN Integrated Services Digital Network 

ISUP ISDN User Part 

I-WLAN Interworking - WLAN 

MAP Mobile Application Part 

MS Mobile Station 

MSC Mobile Switching Centre 

MSISDN MS international PSTN/ISDN number 

MSRN Mobile Station Roaming Number 

NAS Non-Access Stratum 

PSI Public Service Identity 

PSTN Public Switched Telephone Network 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

UE User Equipment 

URI Uniform Resource Identifier 

UTRAN Universal Terrestrial Radio Access Network 

VCC Voice Call Continuity 

VDI VCC Domain Transfer URI 

VDN VCC Domain Transfer Number 

VMSC Visited MSC 

WLAN Wireless Local Area Network 



Overview of voice call continuity between the Circuit- 
Switched (CS) domain and the IP Multimedia (IM) 
Core Network (CN) subsystem 



4.1 



General 



VCC allows a UE employing on the traditional CS domain accessed via either UTRAN or GERAN, and the IM CN 
subsystem accessed by a number of access technologies, e.g. I-WLAN, to have calls flexibly delivered over both the CS 
domain and the IM CN subsystem, and to pass the call from one to the other when access or other conditions alter. 

Voice calls originated by VCC subscribers in both the IM CN subsystem and in the CS domain are subject to anchoring 
in the IM CN subsystem. Similarly voice calls terminated to VCC subscribers are anchored in the IM CN subsystem. 
When anchoring occurs, such calls have a path to the VCC application from either the CS domain or the IM CN 
subsystem, so that the VCC application can be used to provide a domain transfer. If a call from a VCC subscriber is not 
anchored in the IM CN subsystem, domain transfer is not supported for that call. 

In order for the above to occur, the following procedures are supplied within this specification: 

procedures for call origination are specified in Clause 7. 

procedures for call termination are specified in Clause 8; 

procedures for transfer of a call from the CS domain to the IM CN subsystem are specified in Clause 9; 

procedures for transfer of a call from the IM CN subsystem to the CS domain are specified in Clause 10; and 



procedures for initialising a VCC application for a specific subscriber before the VCC UE makes or receives 
calls are specified in Clause 6. 

In this version of this document, VCC cannot be applied to emergency calls, and are not therefore anchored. 
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4.2 Underlying network capabilities 

VCC assumes the use of a number of underlying network capabilities: 

1) provision by the home network operator of VCC specific AS on the IM CN subsystem, as specified in 
3GPPTS 24.229 [8]; 

2) signalling within the CS domain (both within the home network and between the home network and any visited 
network) supported using either ISUP (as defined in ITU-T Recommendations Q.761 to Q.764 [14]) or BICC (as 
defined in ITU-T Recommendations Q. 1902.1 to Q. 1902.6 [15]); 

3) provision of CAMEL Phase 2 or later (as specified in 3GPP TS 29.078 [9]) at the VMSC; 

4) If CAMEL is used for terminating call procedures, provision of CAMEL Phase 2 or later (as specified in 
3GPP TS 29.078 [9]) at the GMSC; 

5) interworking between CS domain and the IM CN subsystem provided by an MGCF in accordance with 
3GPPTS 29.163 [10]; and 

6) capability of the IP-CAN to support full duplex speech component, for example as used in IMS multimedia 
telephony. 

If CAMEL is not used for terminating call procedures, then network configuration is required to ensure that terminating 
calls in the CS domain can be anchored (see subclause A.5.5). In this case the HSS(HLR) is configured to provide the 
IMRN back to any requesting GMSC and subsequent routeing to the IM CN subsystem takes place based on this 
IMRN. As there are no VCC-specific procedures involved, this is not described in clause 7. 

VCC can be provided using the following options to provide the data associated with the IMRN to the DTP: 

1) using a direct communication between the gsmSCF and the CAMEL service function and the DTP; or 

2) using ISUP call diversion mechanisms. If this mechanism is used it requires a MGCF that supports call 
diversion. This option requires appropriate peering arrangements to allow for transparency regarding the call 
diversion related parameters. 

4.3 URI and address assignments 

In order to support VCC to a subscriber the following URI and address assignments are assumed: 

a) in this version of the document, the VCC UE will be configured with both a VDI and a VDN in order to initiate a 
domain transfer. 3GPP TS 24.167 [6] specifies an optional mechanism whereby these parameters can be 
modified; 

b) the VCC UE will be configured to be reachable in both the IM CN subsystem and the CS domain by one to 
many public telecommunication numbers which should be correlated between the CS domain and IM CN 
subsystem. This public telecommunication number can be the MSISDN used in the CS domain and (in 
international form) comprise part of the implicit registration set associated with that VCC UE in the IM CN 
subsystem, or the VCC application can be configured to provide a functional relationship between separate 
numbers providing each of these identities; 

NOTE: One way of correlating the public telecommunication numbers of the CS domain and the IM CN 
subsystem is, to set them to the same values. 

c) an IMRN is assigned that can reach a VCC application that can either support the VCC capabilities for that VCC 
UE, or otherwise locate the VCC application supporting the VCC capabilities for that VCC UE. The IMRNs can 
be dynamically allocated at the time that the call is rerouted to the IM CN subsystem for VCC purposes or 
domain transfers from the IM CN subsystem to the CS domain are accepted. The IM CN subsystem is 
configured to treat the IMRN as a PSI; 

d) the MSISDN will be subject to routeing to the IM CN subsystem in order for anchoring to be performed by the 
VCC application. A CSRN is assigned to be able to route to the VMSC (via an MGCF) such that the CSRN is 
not subject to the same routeing back to the IM CN subsystem and the VCC application. The CSRN can be the 
MSRN for that call; and 
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e) not all calls are suitable for domain transfer, and application of domain transfer to other calls might be against 
subscriber or operator preferences. 3GPP TS 22.101 [1] Clause 21 provides the requirements for this. 
Subclause 5.5 of the present document specifies an additional prerequisite for allowing VCC to be applied to 
calls. 



5 Functional entities 

5.1 Introduction 

This clause associates the functional entities described for the IM CN subsystem and for the CS domain, with the VCC 
roles described in the stage 2 architecture document (see 3GPP TS 23.206 [3]). 

5.2 User Equipment (UE) 

To be compliant with this document, a UE shall implement the role of a VCC UE (see subclause 6.2, subclause 7.2, 
subclause 8.2, subclause 9.2 and subclause 10.2). 

5.3 Media Resource Function Controller (MRFC) 

There are no roles specific to VCC associated with the MRFC. 

5.4 Application Server (AS) 

The VCC application provides the following roles: 

a) Domain Transfer Function (DTF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.1; 

b) Domain Selection Function (DSF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.2; 

c) CS Adaptation Function (CSAF) as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.3; 

d) CAMEL service function as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.4. 

An AS implementing the VCC application shall implement one or more of the roles DTF, DSF or CSAF. The CSAF 
cooperates with a CAMEL Service Function as defined in 3GPP TS 23.206 [3] subclause 5.3.1.2.4 in order to provide 
VCC functionality. All four roles can be co-located. 

5.5 Media Gateway Control Function (MGCF) 

In order to support VCC for any call, the MGCF has to provide signalling interworking and control of the media 
between the CS domain and the IM CN subsystem. The VCC application can only be configured to operate where 
appropriate interworking is provided, e.g. a voice call represented by SDP in the IM CN subsystem has an equivalent 
coding in the transmission media requirement and optionally the ISUP USI parameter in the CS domain. 

As the procedures for call termination in the CS domain may involve an MGCF provided by another network operator, 
the provision of appropriate interworking can extend to peering agreements between operators. 

6 Roles for registration in the IM CN subsubsystem 
6.1 Introduction 

The VCC application can be configured with any of various options for obtaining information from the IM CN 
subsystem specified in 3GPP TS 24.229 [8], 3GPP TS 29.328 [11] and 3GPP TS 29.329 [12], for example: 
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a) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application; 

b) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application. 
The VCC application then subscribes to the reg event package for that user to obtain information; or 

c) receipt of REGISTER request which causes a third-party REGISTER request to be sent to the VCC application. 
The VCC application then uses the Sh interface to obtain information. 

This document places no requirement on the use of all or any of these mechanisms. 

6.2 VCC UE 

There are no VCC specific requirements for registration of the VCC UE to the the IM CN subsystem. 

NOTE 1: Depending on operator policy, registration to the IM CN subsystem can impact whether calls are 
delivered to the VCC UE using the IM CN subsystem or using the CS domain. 

NOTE 2: The VCC UE performs registration in the IM CN subsystem independent of the UE"s state in the CS 
domain. 



6.3 VCC application 



The VCC application can obtain information from any received third-party REGISTER request, or any received reg 
event package, or the Sh interface, that it needs to implement the domain selection policy of the network operator. 

If the third-party REGISTER request does not carry a P- Access-Network-Info header provided by the UE, and the VCC 
application requires this knowledge in for domain selection procedures, the mechanisms by which the VCC application 
determines the domain are outside the scope of this version of the specification, but could be dependent on configurable 
parameters in the DSF. 



Roles for call origination 



7.1 Introduction 

This clause specifies the procedures for call origination, both where the VCC UE is generating calls in the CS domain 
and where the VCC UE is generating calls using the IM CN subsystem. Procedures are specified for the VCC UE and 
the various functional entities within the VCC application, and for the CAMEL service function towards the gsmSCF. 

Subclause A.4 gives examples of signalling flows for call origination. 

7.2 VCC UE 

The VCC UE shall support origination of calls suitable for VCC both via the CS domain (as specified in 
3GPP TS 24.008 [5]) and the IM CN subsystem (as specified in 3GPP TS 24.229 [8]). 

There are no VCC specific requirements for the origination of calls that may be subject to VCC. 

NOTE 1 : For INVITE requests initiated by the VCC UE in the IM CN subsystem, the following SIP response codes 
can indicate failure of the VCC application to process the request with its current characteristics: 

484 (Address Incomplete); 

- 488 (Not Acceptable Here) or 606 (Not Acceptable); 

503 (Service Unavailable) or 603 (Decline). 

NOTE 2: For SETUP messages initiated by the VCC UE in the CS domain, the following cause codes in a response 
message can indicate failure of the VCC capability to process the request with its current characteristics: 
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- #21 "Call rejected"; 

#28 "Invalid number format (address incomplete); 
#127 "Interworking, unspecified". 

7.3 VMSC 

There is no VCC specific procedure at the VMSC. 

NOTE: the VMSC interacts with CAMEL to proceed with the call origination. 



7.4 VCC application 



7.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to call origination: 

SIP INVITE requests routed to the VCC application over either the ISC interface or the Ma interface using the 
IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, and which 
are known by interaction with the gsmSCF functionality to relate to an originating request rather than a domain 
transfer request or a terminating request. In the procedures below such requests are known as "SIP INVITE 
requests due to originating IMRN". These requests are routed firstly to the CSAE and then to the DTP; and 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the origination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.2), are 
distinguished by the contents of the Request-URI. If the Request-URI contains a VDI, then it is for a domain 
transfer request. However, absence of a VDI in the Request-URI indicates an origination request. In the 
procedures below such requests are known as "SIP INVITE requests due to originating filter criteria". These 
requests are routed firstly to the DTE. 

Subclause 8.4.1, subclause 9.3.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The VCC application (CAMEL service function) also processes requests from the gsmSCF via a protocol not defined in 
this version of the specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 

interface between VMSC and gsmSCF, and is depending whether it relates to an originating request, 
containing an ordinary called party number, or relates to a domain transfer request, which contains a 
VDN as the called party number. 

7.4.2 Call origination in the IM CN subsystem 

When the DTE receives a SIP INVITE request due to originating filter criteria, the DTE shall: 

1) check anchoring is possible for this session; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, the present IP-CAN used to access the IM CN 
subsystem.. In general, the number of calls presented for anchoring on behalf of the same user, and the 
media characteristics relating to these calls, will not prevent anchoring, as these issues are dealt with at 
domain transfer. 

NOTE 2: Some checks can also form part of the initial filter criteria in the S-CSCF to determine if the SIP INVITE 
request is sent to the DTE in the first place, e.g. values of the P- Access-Network-Info header header could 
form part of the initial filter criteria. 
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2) if the session is not subject to anchoring, either: 

a) forward the SIP INVITE request by acting as a SIP proxy as specified in subclause 5.7.4 of 

3GPP TS 24.229 [8], and therefore allow the call to continue without anchoring. The DTP shall not Record- 
Route on such requests, and the request is not retargetted by changing the Request-URI; or 

b) reject the SIP INVITE request. The following SIP response codes are recommended: 

- 484 (Address Incomplete), if the Request-URI supplied is not resolvable in the home network (such a 
Request-URI may have been resolvable in the local network which may be visited by the VCC UE at this 
time); 

- 488 (Not Acceptable Here) or 606 (Not Acceptable), if some aspect of operator policy precluded 
anchoring; or 

503 (Service Unavailable) or 603 (Decline) for all other conditions; 

and no further VCC specific procedures are performed on this session; and 

3) if the session is subject to anchoring, operate as an application server providing 3"" party call control, and 
specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all 
future requests and responses in the same dialog with the following additions: 

copy the Request-URI unchanged from the incoming SIP INVITE request to the outgoing SIP INVITE 
request; 

copy all other headers unchanged from the received SIP INVITE request to the outgoing SIP INVITE 
request; and 

copy the body unchanged from the received INVITE request to the outgoing SIP INVITE request. 

NOTE 3: Call anchoring is performed before all originating services are executed and thus the DTE is invoked as 
the first AS in the originating initial Filter Criteria. Example initial Filter Criteria can be found in 
annex B. 

7.4.3 Call origination in the CS domain - procedures towards the gsmSCF 

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to an 
originating call, containing a called party number that is not a VDN, the CAMEL service function shall: 

1) check anchoring is possible for this call; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
IMRNs or a lack of translation rules if the called party number is not in an international number format. 
In general, the number of calls presented for anchoring on behalf of the same user will not prevent 
anchoring, as these issues are dealt with at domain transfer. 

2) if the session is not subject to anchoring, cause the gsmSCF to respond with a CAMEL CONTINUE and no 
further VCC specific procedures are performed on this call; and 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

3) if the session is subject to anchoring, allocate an IMRN or use the CSAF to allocate an IMRN. The IMRN is 
such that when the VCC application receives a SIP INVITE request it can derive by inspection that the request is 
due to an originating IMRN. How IMRNs are allocated may vary from one VCC application to another and is 
not specified in this version of the specification; 

4) if the session is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message, as 
specified in 3GPP TS 29.078 [9], with the Destination Routing Address set to the IMRN, and optionally, the 
Original Called Party ID, the Redirecting Party ID; and the Redirection Information. 

NOTE 3: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 
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NOTE 4: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

7.4.4 Call origination in the CS domain - procedures towards IM CN 
subsystem 

When the CSAF receives SIP INVITE request due to originating IMRN, the CSAF and DTP in combination shall: 

1) operate as an application server providing 3'^'' party call control, and specifically as an initiating B2BUA, as 
specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the 
same dialog; 

2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the original called 
party number of the call as initiated in the CS domain. The tel-URI may be available from information associated 
with the received IMRN or from the History-Info header; 

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the original 
called party number of the call as initiated in the CS domain. The tel-URI may be available from information 
associated with the received IMRN or from the History-Info header; 

4) if the CSAF has received a History-Info header having an index parameter indicating only one diversion, not 
include the History-Info header; 

NOTE 1 : The History-Info header was received as a result of the option of using ISUP call diversion mechanisms 
to transfer VCC specific information and carries no information relating to a real diversion. 

5) insert a Route header pointing to the S-CSCF serving the VCC UE, or to the entry point of the VCC UE"s 
network (e.g., I-CSCF) and append the orig parameter to that same Route header of the outgoing initial SIP 
INVITE request; and 

6) set the P-Asserted-Identity header of the outgoing SIP INVITE request and to a tel-URI which represents the 
calling party number of the call initiated in the CS domain. This is either available from information associated 
against the received IMRN or is the value as received in P-Asserted-Identity header of the incoming SIP INVITE 
request. 

NOTE 2: It can happen that the P-Asserted-Identity header is not included in the incoming SIP INVITE request. 

The CSAF and DTF in combination should in the outgoing SIP requests and SIP responses include the same values as 
received in the incoming SIP requests and SIP responses in all other headers with the exception given in this subclause 
and in subclause 5.7.5 of 3GPP TS 24.229 [8]. 

The DTF will handle the Privacy header in the outgoing SIP INVITE request in the following way. The DTF shall 
either: 

if a Privacy header is received in the incoming INVITE request, include the Privacy header as received in the 
incoming INVITE request; or 

if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the 
CS domain, include a Privacy header with the value set to "id". 

Editor's note: Other actions are required to be specified, since the VCC AS works as an initiating B2BUA. 

Editor's note: The value of the P-Asserted-Identity header needs to be specified. 

On completion of the above procedure, the call is anchored in the DTF. 

NOTE 3: After completion of anchoring the call in DTF, the allocated IMRN is available for reuse. 
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8 Roles for call termination 

8.1 Introduction 

This clause specifies the procedures for call termination, both where the VCC UE is receiving calls in the CS domain 
and where the VCC UE is receiving calls using the IM CN subsystem. Procedures are specified for the VCC UE and the 
various functional entities within the VCC application, and if the CAMEL service function is used, for the CAMEL 
service function towards the gsmSCF. 

Subclause A.5 gives examples of signalling flows for call termination. 

8.2 VCC UE 

The VCC UE shall support termination of calls suitable for VCC both via the CS domain (as specified in 
3GPP TS 24.008 [5]) and the IM CN subsystem (as specified in 3GPP TS 24.229 [8]). 

There are no VCC specific requirements for the termination of calls that may be subject to VCC. 

8.3 GMSC 

There is no VCC specific procedure at the GMSC. 

NOTE: Call diversion from CS domain to IM CN subsystem is required to proceed call termination. Several 

techniques are available at the GMSC to implement the call diversion as described in 3GPP TS 23.206 [8] 
Annex A. Those techniques are implementation options. 

8.4 VCC application 

8.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to call termination: 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the termination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.3), and 
therefore distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the 
Route header. In the procedures below such requests are known as "SIP INVITE requests due to terminating 
filter criteria". These requests are routed to the DTP and then to the DSF; and 

SIP INVITE requests routed to the VCC application over the Ma or ISC interface using the IMRN as a PSI, and 
therefore distinguished by the presence of the IMRN in the Request-URI header, which is different from the 
VDN. In the procedures below such requests are known as "SIP INVITE requests due to terminating IMRN". 
These requests are routed firstly to the CSAF and then to the DTP and then to the DSF. 

Subclause 7.4.1, subclause 9.3.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The CAMEL service function also processes requests from the gsmSCF via a protocol not defined in this version of the 
specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 
interface between GMSC and gsmSCF. 



£75/ 



3GPP TS 24.206 version 7.3.0 Release 7 1 6 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

8.4.2 Call termination in the IM CN subsystem 

When the VCC apphcation receives a SIP INVITE request due to terminating filter criteria: 

1) the DTP shall check anchoring is possible for this session; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
CSRNs. In general, the number of calls presented for anchoring on behalf of the same user will not 
prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the 
user without anchoring. 

NOTE 2: Such a check can also form part of the initial filter criteria in the S-CSCF to determine if the SIP INVITE 
request is sent to the DTP in the first place. 

2) if the session is not subject to anchoring, the DTP shall forward the SIP INVITE request by acting as a SIP proxy 
as specified in subclause 5.7.4 of 3GPP TS 24.229 [8]. The DTP shall not Record-Route on such requests and no 
further VCC specific procedures are performed on this session; 

3) if the session is subject to anchoring, the DTP shall operate as an application server providing 3"* party call 
control, and specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this 
request and all future requests and responses in the same dialog; 

4) the DSP shall perform domain selection based on: 

operator preferences; 

callee capabilities of the terminating UE, as obtained during registration; 

access network information, as provided in the P- Access-Network-Info header of the terminating UE; 

call states; and 

whether the session has characteristics other than audio media; 

NOTE 3: The media characteristics can be derived from SDP information as well as from further capability 
indications of the terminating UE, such as e.g. callee preferences. 

5) if the IM CN subsystem is selected by the DSP, the DSP or the combination of the DTP and DSP shall leave the 
Request-URI unchanged between the incoming SIP INVITE request and the outgoing SIP INVITE request; and 

6) if the CS domain is selected by the DSP, the DSF shall determine a CSRN optionally using the CSAP and set the 
headers of the outgoing SIP INVITE request as follows: 

a) set the Request-URI of the outgoing SIP INVITE request to the CSRN; and 

b) set the To header field of the outgoing SIP INVITE request to the CSRN; 

NOTE 4: The SIP AS that implements the DSF or the combination of the DTP and DSP acting as a B2BUA - 

which performs the third-party call control - needs to be the last located application server to ensure that 
all application servers that need to remain in the path of a call after domain transfer will do so. Example 
initial Filter Criteria can be found in Annex B. 

On completion of the above procedure, the call is anchored in the DTP. 

In the case where call delivery attempt fails in the selected domain and where the operator policy requires it, the DSP in 
the VCC application may re-attempt the call setup to the other domain. If this call delivery also fails no further call 
attempts shall be made. 

8.4.3 Call termination in the CS domain - procedures towards the 
gsmSCF 

When the CAMEL service function receives an indication that the gsmSCP has received a CAMEL IDP relating to a 
terminating call, the CAMEL service function and DTP in combination shall: 
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1) check anchoring is possible for this call; 

NOTE 1 : The conditions that prevent anchoring are a matter for implementation, but can include operator policy on 
a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available 
IMRNs. In general, the number of calls presented for anchoring on behalf of the same user will not 
prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the 
user without anchoring. 

2) if the call is not subject to anchoring, cause the gsmSCF to respond with a CAMEL CONTINUE and no further 
VCC specific procedures are performed on this call; and 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

3) if the call is subject to anchoring, allocate an IMRN or use CS AF to allocate an IMRN. How IMRNs are 
allocated may vary from one VCC application to another and is not specified in this version of the specification; 

NOTE 3: For call termination, different options on IMRN derivation are available as described in 
3GPP TS 23.206 [8] Annex A. 

4) if the call is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message with the 
Destination Routing Address set to the IMRN. 

NOTE 4: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 

NOTE 5: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

8.4.4 Call termination in the CS domain - procedures towards IM CN 
subsystem 

When the CSAF receives SIP INVITE request due to terminating IMRN, the CSAF and DTF in combination shall: 

NOTE 1: All SIP INVITE requests directed to the VCC application using an IMRN are assumed to be suitable for 
VCC anchoring, because any checks have been performed in conjunction with the CAMEL procedures. 

1) operate as an application server providing 3"* party call control, and specifically as a routeing B2BUA, as 
specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the 
same dialog; 

NOTE 2: The SIP AS that implements the DTF acting as a B2BUA - which performs the 3"* party call control - 

needs to be the last located application server to ensure that all application servers that need to remain in 
the path of a call after domain transfer will do so. Example initial Filter Criteria can be found in annex B. 

2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the called party 
number of the original call as terminated in the CS domain. The tel-URI may be available from the received 
IMRN or from the "History-Info" header; and 

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the called party 
number of the original call as terminated in the CS domain. The tel-URI may be available from the received 
IMRN or from the "History-Info" header. 

NOTE 3: If call diversion parameters from the "History-Info" header are used to retrieve the original called party 
number and the VCC call was subject to call diversion before it was routed to the GMSC, the DTF will 
restore the original call diversion information. If multiple call diversion has occurred, the redirecting 
number can be lost. 



£75/ 



3G PP TS 24.206 version 7.3.0 Release 7 1 8 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

9 Roles for domain transfer of a call from the CS 

domain to the IM CN subsystem 

9.1 Introduction 

This clause specifies the procedures for domain transfer of a call from the CS domain to the IM CN subsystem. 
Procedures are specified for the VCC UE and the various functional entities within the VCC application. 

Subclause A.6 gives examples of signalling flows for domain transfer of a call from the CS domain to the IM CN 

subsystem. 

9.2 VCC UE 

If the VCC UE: 

is not engaged in an ongoing MPTY service (as specified in 3GPP TS 24.084 [5A]) that it is in control of; 

by evaluating the operator policy (as specified in 3GPP TS 24.216 [6B]) and the radio conditions, determines 
that an ongoing call in the CS domain needs to be supported over the IM CN subsystem instead; and 

has successfully registered the contact address that will be used to support the ongoing call in the IM CN 

subsystem; 

then the VCC UE shall initiate the release of all the ongoing calls in the CS domain that are currently not active. The 
VCC UE can receive the operator policy via OMA Device Management. When the VCC UE receives the operator 
policy, it shall take this information in account when selecting the domain (either CS domain or IM CN subsystem) to 
initiate calls/session and when deciding to perform domain transfer. 

If the UE is engaged in more than one ongoing caUs/sessions and the domain transfer is restricted in this case by the 
specific VCC operator policy, such restriction does not apply in the case the VCC UE is losing coverage in the 
transferring-out domain. 

NOTE 1 : The UE can continue the domain transfer even if the release of the held calls failed to complete (e.g., due 
to radio conditions). 

By an ongoing call, it is meant a call for which the CC CONNECT message has been sent or received. Afterwards the 
VCC UE shall send a SIP INVITE request in accordance with 3GPP TS 24.229 [8] subclause 5.1. The VCC UE shall 
populate the SIP INVITE request as follows: 

1) the Request-URI set to the VDI; 

2) the To header field set to the VDI; 

3) the P-Preferred-Identity header field set to a public telecommunication number in accordance with subclause 4.3; 

and 

Editors Note: It is for FES how the UE determines which Public User ID's to register and then subsequently use to 
ensure that requirement in 3) is met. 

4) the SDP payload set for a single media line with media type "audio", indicating all supported codecs for this 
media type, in accordance with subclause 6.1.1 and subclause 6.1.2 of 3GPP TS 24.229 [8]. 

If the VCC UE receives any SIP 4xx - 6xx response to the SIP INVITE request, then domain transfer has not occurred 
and the call will continue in the CS domain. 

NOTE 2: If the VCC UE receives a SIP 480 (Temporarily Unavailable) response to the SIP INVITE request, then 
this can indicate that the VCC appUcation was unable to correlate the request to a single anchored call in 
the CS domain. 



ETSI 



3GPP TS 24.206 version 7.3.0 Release 7 1 9 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

NOTE 3: If the VCC UE receives a SIP 488 (Not Acceptable Here) response or a 606 (Not Acceptable) response to 
the SIP INVITE request, then this can indicate that the remote terminal was not able to support the media 
characteristics of the SIP INVITE request, e.g. because the remote user is in the CS domain and the 
MGCF/MGW in the path does not support the specified interworking. 

When the VCC UE receives a CC DISCONNECT message from the network, the VCC UE shall comply with network 
initiated call release procedures as specified in 3GPP TS 24.008 [5]. 

9.3 VCC application 

9.3.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to domain transfer: 

SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria 
at the S-CSCF according to the origination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.2), and therefore 
distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the Route 
header, but which contains a VDI belonging to the subscribed user as the Request-URL In the procedures below 
such requests are known as "SIP INVITE requests due to VDI". These requests are routed to the DTF. 

Subclause 7.4.1, subclause 8.4.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

9.3.2 Domain transfer in the IM CN subsystem 

When the DTF receives a SIP INVITE request due to VDI, the DTF shall associate the SIP INVITE request with an 
ongoing SIP dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP 
INVITE request has been sent or received. Multiple dialogs relating to the same VCC UE can be anchored, in which 
case the identification of the associated dialog is subject to the following conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a 2xx response has 
been sent and there is active audio media, then continue the domain transfer procedures; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the domain transfer; 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the DTF may release the inactive dialogs and 
continue the domain transfer procedures or the DTF may send a SIP 480 (Temporarily Unavailable) response 
to reject the SIP INVITE request relating to the domain transfer. 

Continuing the domain transfer procedures, the DTF sends a SIP relNVITE request towards the remote user using the 
existing established dialog. The DTF shall populate the SIP relNVITE request as follows: 

set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote user; and 

a new SDP offer, including the media characteristics as received in the SIP INVITE request due to VDI, by 
following the rules of the 3GPP TS 24.229 [8]. 

Upon receiving the SIP ACK request from the IM CN Subsystem, the DTF shall initiate release of the old access leg by 
sending a SIP BYE request toward the MGCF. 

If, subsequent to initiating the SIP relNVITE request to the remote user, and prior to the SIP ACK request being 
received from the IM CN subsystem for the old access leg, the DTF decides (for any reason) to reject the domain 
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transfer request back to the UE (e.g. by sending a 4xx response), the DTP shall release the new access leg and maintain 
the old access leg. 

9.4 MGCF 

There are no VCC specific procedures at the MGCF beyond those specified by 3GPP TS 29.163 [10]. 

NOTE: When the SIP BYE request is received, the MGCF translates the SIP BYE request to an ISUP REL 

message as specified in 3GPP TS 29.163 [10] and forwards this to the VMSC. The VMSC responds with 
ISUP RLC message and performs network initiated call release as specified in 3GPP TS 24.008 [5]. 

1 Roles for domain transfer of a call from the IM CN 
subsystem to the CS domain 

10.1 Introduction 

This clause specifies the procedures for domain transfer of a call from the IM CN subsystem to the CS domain. 
Procedures are specified for the VCC UE and the various functional entities within the VCC application, and if the 
CAMEL service function is used, for the CAMEL service function towards the gsmSCF. 

Subclause A.7 gives examples of signalling flows for domain transfer of a call from the IM CN subsystem to the CS 
domain. 

10.2 VCCUE 

If the VCC UE is not engaged in an ongoing SIP conferencing service (as specified in 3GPP TS 24.173 [6A]) that it is 
in control of and, by evaluating the operator policy (as specified in 3GPP TS 24.216 [6B]) and the radio conditions, 
determines that an ongoing SIP dialog in the IM CN subsystem should be transferred to the CS domain, then the VCC 
UE shall initiate the release of all the ongoing SIP dialogs in the IM CN subsystem. By an ongoing SIP dialog, it is 
meant a dialog for which a SIP 2xx response to the initial INVITE request has been sent or received. The VCC UE can 
receive the operator policy via OMA Device Management. When the VCC UE receives the operator policy, it shall take 
this information in account when selecting the domain (either CS domain or IM CN subsystem) to initiate calls/session 
and when deciding to perform domain transfer. 

If the UE is engaged in more than one ongoing calls/sessions and the domain transfer is restricted in this case by the 
specific VCC operator policy, such restriction does not apply in the case the VCC UE is losing coverage in the 
transferring-out domain. 

NOTE 1 : The UE can continue the domain transfer even if the release of the held calls failed to complete (e.g., due 
to radio conditions). 

Afterwards the VCC UE shall send a CC SETUP message in accordance with 3GPP TS 24.008 [5]. The VCC UE shall 
only send this request if the ongoing SIP dialog in the IM CN subsystem has had the dialog accepted, i.e. a SIP 200 
(OK) response to the SIP INVITE request has already been sent. 

NOTE 2: If the VCC UE has multiple calls in the IM CN subsystem at this time, then these calls could all be 
anchored. It is the responsibility of the VCC UE to ensure that the domain transfer request can be 
resolved by the DTF to a single call. 

NOTE 3: The current media characteristics of the call in the IM CN subsystem does not preclude domain transfer, 
as the media characteristics are renegotiated as part of the domain transfer. 

The VCC UE shall populate the CC SETUP message as follows: 

1) the called party BCD number information element set to the VDN; and 

2) [need to ensure suitable bearer characteristics] 
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NOTE 4: If the VCC UE receives a release message containing a #20 "Subscriber absent" cause value to the CC 
SETUP message, then this can indicate that the VCC application was unable to correlate the request to a 
single anchored call in the IM CN subsystem. 

NOTE 5: If the VCC UE receives a release message containing a #127 "Interworking, unspecified" cause value to 
the CC SETUP message, then this can indicate that the remote terminal was not able to support the media 
characteristics of the CC SETUP message. 

NOTE 6: If the VCC UE receives a release message containing a #63 "Service or option not available" cause value 
to the CC SETUP message, then this can indicate that the domain transfer was not successful. 



10.3 VMSC 

There is no VCC specific procedure at the VMSC. 

10.4 VCC application 



1 0.4.1 Distinction of requests sent to tine VCC application 

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific 
functionality relating to domain transfer: 

SIP INVITE requests routed to the VCC application over either the ISC interface or the Ma interface using the 
IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, and which 
are known by interaction with the gsmSCF functionality to relate to a domain transfer request rather than an 
originating request or terminating request. In the procedures below such requests are known as "SIP INVITE 
requests due to domain transfer IMRN". These requests are routed to the DTE. 

Subclause 7.4.1, subclause 8.4.1 and subclause 9.3.1 detail other procedures for initial INVITE requests with different 
recognition conditions. 

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner 
conformant with 3GPP TS 24.229 [8]. 

The VCC application (CAMEL service function) also processes requests from the gsmSCF via a protocol not defined in 
this version of the specification. 

NOTE: The functionality associated with these requests is described, based on the actions occurring at the 

interface between VMSC and gsmSCF, and is depending whether it relates to an originating request, 
containing an ordinary called party number, or relates to a domain transfer request, which contains a 
VDN as the called party number. 

1 0.4.2 Domain transfer procedures towards the gsmSCF 

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to an 
originating call, containing a called party number that is a VDN, the CAMEL service function shall: 

1) check whether domain transfer is possible; 

NOTE 1 : The conditions that prevent handover are a matter for implementation, but in general for this check are a 
matter of lack of resources, e.g. available IMRNs. For other checks the request will be continued so 
further checks can be performed at the VCC application within the IM CN subsystem. 

2) if the call is not subject to domain transfer, cause the gsmSCF to respond with a CAMEL RELEASE CALL and 
no further VCC specific procedures are performed on this call. The following cause codes are recommended: 

#63 "Service or oiption not available" if there are insufficient resources, e.g. available IMRNs, to continue 
the handover; 

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 
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3) if the call is subject to domain transfer, allocate an IMRN or use CSAF to allocate IMRN. The IMRN is such that 
when the VCC application receives a SIP INVITE request it can derive by inspection that the request is due to a 
domain transfer IMRN. How IMRNs are allocated may vary from one VCC application to another and is not 
specified in this version of the specification; 

4) if the call is subject to domain transfer, cause the gsmSCF to respond with a CAMEL CONNECT message with 
the Destination Routing Address set to the IMRN. 

NOTE 3: The IMRN assigned for a domain transfer request can be different from the one assigned for CS 

origination (different target PSI i.e. different subfunction of the VCC application) and can be used as an 
indication of a domain transfer request. 

NOTE 4: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the 
service key that was received in the CAMEL IDP. 

NOTE 5: The final decision on the CAP message sent by the gsmSCF depends on the further service logic 
associated with the service key. 

1 0.4.3 Domain transfer in tine IM CN subsystem 

When the CSAF receives SIP INVITE request due to domain transfer IMRN, the CSAF and DTF in combination shall 
associate the SIP INVITE request with an ongoing SIP dialog based on information associated with the received IMRN 
or based on information from the SIP History Info header field and P-Asserted header field and send a SIP relNVITE 
request towards the remote user using the existing established dialog. By an ongoing SIP dialog, it is meant a dialog for 
which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs relating to the 
same VCC UE can be anchored, in which case the identification of the associated dialog is subject to the following 
conditions: 

if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response 
has been sent and there is active audio media, then continue the domain transfer; 

if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio 
media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject 
the SIP INVITE request relating to the domain transfer; 

if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one 
dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then: 

if the remaining dialogs have inactive audio media, then the DTF may release the inactive dialogs and 
continue the domain transfer procedures or the DTF may send a SIP 480 (Temporarily Unavailable) response 
to reject the SIP INVITE request relating to the domain transfer. 

Continuing the domain transfer procedures, the DTF shall populate the SIP relNVITE request as follows: 

set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with 
the remote user; and 

a new SDP offer, including the media characteristics as received in the SIP INVITE request due to domain 
transfer IMRN, by following the rules of the 3GPP TS 24.229 [8]. 

NOTE: The History-Info header field was received as a result of the option of using ISUP call diversion 

mechanisms to transfer VCC specific information and carries no information relating to a real diversion. 

NOTE 1 : On completion of the above procedure, the allocated IMRN is available for reuse. 

Upon receiving the SIP ACK request from the IM CN subsystem, the DTF shall initiate release of the old access leg by 
sending a SIP BYE request toward the S-CSCF for sending to the served VCC UE. 
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Annex A (informative): 

Example signalling flows of voice call continuity between the 
Circuit-Switched (CS) domain and the IP Multimedia (IM) 
Core Network (CN) subsystem 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for voice call continuity between the Circuit-Switched (CS) domain and 
the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events. 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.206 [3]. 



A.2 Introduction 
A.2.1 General 

The signalling flows provided in this annex follow the methodology developed in 3GPP TS 24.228 [7]. The following 
additional considerations apply: 

a) 3GPP TS 24.228 [7] shows separate signalling flows with no configuration hiding between networks, and with 
configuration hiding between networks. There is no voice call continuity specific functionality associated with 
this hiding, and therefore such separate signalling flows are not show in the present document; 

b) 3GPP TS 24.228 [7] does not show the functionality between the S-CSCF and the AS. As voice call continuity 
depends on the functionality provided by various AS, the signalling flows between S-CSCF and AS are shown in 
the present document; 

c) 3GPP TS 24.228 [7] breaks down the functionality of the various CSCFs. Such intervening activity in the CSCFs 
is in general not relevant to showing the functionality within voice call continuity, and therefore the CSCFs are 
collapsed into a single entity labelled "Intermediate IM CN subsystem entities"; 

d) where entities are combined as in c) above, and the signalling flow is directed to such a combined entity, the 
contents of the signalling flow represent the contents of the sending entity; 

e) where entities are combined as in c) above and the signalling flow originates at such a combined entity, the 
contents of the signalling flow represent the contents of the receiving entity; and 

f) within the CS domain, both ISUP and BICC can be used. The signalling flows represent only the ISUP 
signalling flows, and the BICC signalling flows (which can be assumed to be similar with no additional VCC 
specific content) are not shown. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [7] subclauses 4. 1 and 4.2 applies with the additions 
specified below: 

- tel:H-l-241-555-3333 represents the IMRN associated with a call made by UE#1. 

sip:dtfl. homel.net represents the address within the originating IM CN subsystem of the AS providing the DTF. 
sip:dtf2.home2.net represent the address within the terminating IM CN subsystem of the AS providing the DTF. 

- tel:H-l-241-555-4444 represents the CSRN associated with a call made by UE#1. 
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- tel:+l-212-555-5555 represents the VDN associated with UE#1. 

sip:domain.xfer@dtf 1 .homel .net represents the VDI associated with UE#1 . 

sipxsafl. homel.net represents the address of the AS providing the CSAF and therefore the address stored 
against the PSI. 

Each signalHng flow table contains descriptions for headers where the content of the header is new to that signalling 
flow, as is already performed in 3GPP TS 24.228 [7]. 

However, 3GPP TS 24.228 [7] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the signalling flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [7], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [7] in addition to the material 
shown in the present document. 

In order to differentiate between messages for SIP and media, the notation in figure A. 2-1 is used. 



INVITE 



SETUP 



-► SIP message 

-► CS message 

►" Media over a PS connection 

► Media over a CS connection 



Figure A.2-1 : Signalling flow notation 



A.3 Signalling flows for registration and exchange of 
mobility status information 

There are no VCC specific signalling flows. 

A. 4 Signalling flows for call origination 
A.4.1 Introduction 

The signalling flows for call origination demonstrate how a VCC UE, on originating a call, is anchored for the purposes 
of a future domain transfer. The following signalling flows are included: 

subclause A.4.2 shows the successful anchoring for a call originated using the IM CN subsystem; 

subclause A.4.3 shows the successful anchoring for a call originated using the CS domain, by routeing the call to 
the IM CN subsystem using CAMEL; 

subclause A.4.4 shows the successful anchoring for a call originated using the CS domain, by routeing the call to 
the IM CN subsystem using CAMEL and routeing the call from the VCC application to the terminating 
subscriber using information received in the SIP History-Info header; 

subclause A.4.5 shows a call originated from the CS domain for which the anchoring is denied; the call is 
continued in the CS domain; and 
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subclause A. 4. 6 shows the origination of a call in the CS domain that is capable of being subject to VCC when 
the user is not currently registered within the IMS CN subsystem. 

A.4.2 Signalling flows for origination from the IM CN subsystem 

Editors note: When stage 2 specification has become clearer regarding how supplementary services shall be 

provided it may be needed to add an additional AS to test that the services are executed in the same 
manner indepent from where the session is initiated. 
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Figure A.4.2-1 : Signalling flow for origination from the IM CN subsystem 



ETSI 



3GPP TS 24.206 version 7.3.0 Release 7 26 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

1 . Determination of call establishment domain 

As a result of some stimulus to establish a call with full duplex, voice-only call, the VCC UE based on a 
combination of user policy, and access technology availability, decides to establish the call using the IM CN 
subsystem. 

The VCC UE initiates the IM CN subsystem call towards the destination UE by sending a SIP INVITE request 
to the intermediate IM CN subsystem entities. 

2. SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) - see example in table A.4.2-2 

Table A.4.2-2: SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : sip :pcscf 1 .homel .net : 75 31; Ir ; comp=sigcomp> , <sip :orig@scscf 1 .homel .net; lr> 

P-Preferred-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-802 . lib 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel; precondition 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9G ; spi=87654321 ; portl=7531 

Contact: < sip: [5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxpt ime : 2 



Request-URI: the tel-URI of the destination 

3. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities respond to the VCC UE with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

4. Evaluation of initial filter criteria 

In this example, and by evaluation of the initial filter criteria, as this is an originating SIP INVITE request for a 
registered VCC user the S-CSCF routes the SIP INVITE request to the DTP. 

5. SIP INVITE request (intermediate IM CN subsystem entities to DTE) - see example in table A.4.2-5 

The intermediate IM CN subsystem entitities send the SIP INVITE request to the DTP. 

As part of this operation, the S-CSCF adds the address of the DTP and the original dialog identifier. The S- 
CSCF will include the original dialog identifier as a part of the second topmost Route header. The Request-URI 
includes the tel-URI of the destination. 
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Table A.4.2-5: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 . homel . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 

Route : <sip :dtf 1 .homel .net ; lr>, <sip : Cb03a0s09a2sdfglkj490333@scscf 1 .homel .net; lr> 
Record-Route : <sip : scscf 1 . homel . net> 
P-Asserted-Identity: <tel: +l-212-555-llll> 
P-Access-Network-Inf o : 
Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ;orig- 
ioi=type3ashomel . net> 

P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22] 
ecf= [5555 : : If f : 2ee : 3dd : 4ee] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
From: 
To: 

Call-ID: 
Cseq: 127 
Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



6. SIP 100 (Trying) response (DTF to intermediate IM CN subsystem entities) 

The DTF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

7. Anchoring decision 

The DTF performs the anchoring. 

8. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.4.2-8 

Since the service execution continues as an originating case the DTF, after executing the anchoring, sends the 
SIP INVITE request with a Route header that includes the original call identifier in the Route header to the 
intermediate IM CN subsystem entities. 

The DTF works in this case as a routeing B2BUA. In particular, the To and From header fields remain 
unchanged. It will not include any entry in the Record-Route header. The AS does not change any codecs. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.4.2-8: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP dtfl.homel.net; branch=z9hG4bK332b23 . 3 ; 

Max-Forwards: 66 

Route: <sip:cb03aOs09a2sdfglkj490333®scscf 1 .homel .net;lr > 

P-Asserted- Identity : 

P-Access-Network-Info : 

Privacy: none 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 

P-Charging-Function-Addresses : 

From: 

To: 

Call-ID: 

Cseq: 127 

Supported: 

Contact :<sip: [7777: :eee :ddd: ccc : aaa] > 

Allow: 

Content-Type : 

Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Request-URI: includes the tel-URI of the destination. 
Contact: address of the DTF. 

9. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

10. Evaluation of initial filter criteria 

In this example, the S-CSCF continues the triggering from the next trigger point (originating request registered 
user) in the initial filter criteria. Since no more triggering is required in the initial filter criteria, the IM CN 
subsystem will do a ENUM look up and get the SIP-URI for the destination user. 

1 1 . SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see example 
in table A.4.2-11 

The intermediate IM CN subsystem sends a SIP INVITE request towards the terminating side. 
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Table A.4.2-11 : SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP dtfl.homel.net; 

branch=z9jG4bK332b23 .2 
Max- Forwards : 6 5 

Record-Route : sip . scscf 1 . homel . net 
P-Asserted- Identity : 
Privacy: none 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" , orig-ioi=homel .net 
From 
To: 

Call-ID 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v=0 

o= 

s= 

c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the to the intermediate IM CN subsystem entities with a SIP 100 
(Trying) response. 

There is no VCC specific content to this response. 

13a-d. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response / SIP 180 (Ringing) 
response 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-C/VN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

14. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing forwards a SIP 200 (OK) response to the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

15. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

16. SIP 200 (OK) response (DTF to intermediate IM CN subsystem entities) 

The DTF forwards the SIP 200 (OK) response to the intermediate IM CN subsystem entities, using the content of 
the Via header in the received SIP INVITE request (step 5). 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 
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There is no VCC specific content to this response. 

17. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the VCC UE. 
There is no VCC specific content to this response. 

18. SIP ACK request (VCC UE to intermediate IM CN subsystem entities) 

The VCC UE completes the dialog creation with a SIP ACK request sent to the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this request. 

19. SIP ACK request-(intermediate IM CN subsystem entities to DTE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the DTP. 
There is no VCC specific content to this request. 

20. SIP ACK request (DTE to intermediate IM CN subsystem entities) 

The DTP forwards the SIP ACK request to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

21. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this request. 

A.4.3 Signalling flows for origination from CS domain 

Figure A.4.3- 1 shows the origination of a call in the CS domain that is capable of being subject to VCC. 
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Figure A.4.3-1 : CS call origination from the VCC user 
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The details of the signalling flows are as follows: 

1 Determination of call establishment domain 

As a result of some stimulus to establish a full-duplex, voice-only call, the VCC UE based on a combination of 
user policy, and access technology availability, decides to establish the call using the CS domain. 

2. SETUP message (VCC UE to VMSC) 

After establishment of the MM connection, the VCC UE initiates the CS call towards the destination UE by 
sending out the SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM PR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The Called Party Number information element identifies the intended recipient of the call, and the Bearer 
Capability information element and the Supported Codec List information element identify an intended call that 
can be subject to VCC. 

The VMSC knows the calling party number corresponding to the UE. 

3. Origination triggers 

4. CAMEL IDP (VMSC to gsmSCF) 

The VMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the gsmSCF. The 
CAMEL IDP message contains at least: 

- the calling party number; 
the called party number; and 
that the call is voice only. 

5. Anchor decision 

The gsmSCF invokes the service logic to determine whether the call needs to be rerouted to IMS for VCC. The 
CAMEL service function allocates an IMRN and returns it to the gsmSCF. 

6. CAMEL service function to CSAF interaction 

Communication is required between the CAMEL service function and the CSAF in order to ensure that the 
nature of the call associated with the IMRN is known by the CSAF. The signalling to support this 
communication is not specified in this version of the specification. 

7. CAMEL CONNECT (gsmSCF to VMSC) 

The gsmSCF responds to the CAMEL IDP message with a CAMEL CONNECT message containing: 
the Destination Routeing Address set to the IMRN. 

8. ISUP lAM (VMSC to MGCF) 

The VMSC initiates the CS call towards the MGCF by sending out the lAM message. 

Specifically for this signalling flow, the lAM includes: 

Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12415553333)] 
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Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125551 1 1 1)] 

USI parameter = 3.1 kHz audio 

The Called Party Number parameter represents the IMRN allocated for this call. 

9. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.3-9 

The MGCF initiates a SIP INVITE request, containing an initial SDP to the intermediate IM CN subsystem 
entities. 

Table A.4.3-9: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max- Forwards : 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: 10 Orel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxpt ime : 2 



Request-URI: Contains the IMRN, as obtained from CS Networks signalling. 

P-Asserted-Identity: The MGCF inserts the tel-URL containing the subscriber number, as received from the CS 
network. 

SDP The SDP contains a preconfigured set of codecs supported by the MGW based on what is 

received in the ISUP. The codecs selected are speech codecs, for which VCC can be applied. 
See table 10a of 3GPP TS 29.163 [10] 

10. SIP INVITE request (intermediate IM CN subsystem entities to CSAF) - see example in table A.4.3-10 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. In 
this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF 
before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.4.3-10: SIP INVITE request (intermediate IM CN subsystem entities to CSAF) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip : csafl .homel .net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 

3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
ra= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



1 1 . SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

The CSAF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

12. Session anchoring 

The CSAF and DTF in combination act as an initiating B2BUA. The CSAF retrieves the original called party 
number and calling party number associated with the IMRN and places the called party number in the Request- 
URI and the To header of the outgoing request. 

The CSAF and DTF in combination decide that this call will be anchored, based on the type of call and operator 
preferences. 

Editor's note: The following text needs further study. 

The DTF found by the IMRN need not be the most appropriate AS to support the handover of the call on behalf 
of the UE in the IM CN subsystem. In these cases it is possible that the VCC application redirects the call to 
another applications server which provides the future transfer functions on behalf of the VCC user. How this 
occurs is outside the scope of this document. 

13. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. In this example, the subsequent flows assume that a visit has been made to the 
S-CSCF, in association with the the triggering of initial filter criteria, in order to reach the DTF. 

14. VCC application 

The CSAF and DTF in combination act as an initiating B2BUA. The DTF anchors the call to provide VCC 
functionality. 

15. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.4.3-15 
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The DTF forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM CN 
subsystem. In this case it is assumed that the user is registered within the IM CN subsystem. 

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer 
functionality needed to support VCC. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

Table A.4.3-15: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP dtfl.homel.net;branch=z9hG4bK312a32 .1 

Max- Forwards : 66 

Route : <sip : s-cscf . homel . net ; Ir ; orig> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call -ID: dcl4bltlOb3teghmlk5 01444 
Cseq: 

Supported: 

Contact: <sip :dtfl .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Contact header: The Contact header represents the contact of the DTF. 

16. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

17. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.3-17 

The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side processing. In 
this example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 
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Table A.4.3-17: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

dtf 1 .homel .net;branch=z9hG4bK312a32 . 1 
Max- Forwards : 65 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type: 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



18. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

19. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no VCC specific actions associated 
with this step. 

The DTF and CS/VF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

20. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

21. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

22. Interaction between DTF and CSAF 
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Information is exchanged between the CS AF and the DTF. The nature of this signalhng is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

23. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities) 

The CSAF forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

24. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no VCC specific content to this response. 

25. ISUP ANM (MGCF to VMSC) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
VMSC. 

There is no VCC specific content to this response. 

26. CONNECT message (VMSC to VCC UE) 

The VMSC sends a CONNECT message to the VCC UE. 
There is no VCC specific content to this response. 

27. CONNECT ACKNOWLEDGE message (VCC UE to VMSC) 

The VCC UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message. 
There is no VCC specific content to this response. 

28. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

29. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

30. SIP ACK request (intermediate IM CN subsystem entities to CSAF) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the CSAF. 
There is no VCC specific content to this response. 

31. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

32. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF forwards the SIP ACK request back to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 
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33. SIP ACK request (intermediate EM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this response. 

A.4.4 Signalling flows for origination from CS domain, using ISUP 
call diversion mechanisms 

Figure A.4.4- 1 shows the origination of a call in the CS domain that is capable of being subject to VCC. In the example 
below it is assumed that the gsmSCF based on the service key returns the parameters Original Called Party ID, 
Redirecting Party and Redirection information. Further it is assumed that the corresponding ISUP parameters are later 
on mapped in the MGCF to appropriate SIP header fields. 
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Figure A.4.4-1 : CS call origination from the VCC user 
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The details of the signalling flows are as follows: 

1 Determination of call establishment domain 

As a result of some stimulus to establish a full-duplex, voice-only call, the VCC UE based on a combination of 
user policy, and access technology availability, decides to establish the call using the CS domain. 

2. SETUP message (VCC UE to VMSC) 

After establishment of the MM connection, the VCC UE#1 initiates the CS call towards UE#2 by sending out the 
SETUP message. 

Specifically for this signalling flow, the SETUP message includes: 

Called Party Number information element = [(Numbering plan identifier = ISDN/telephony numbering plan), 
(type of number = international number ), (Number digits = 12125552222)] 

Bearer Capability information element = [(information transfer capability = speech), (speech versions = FR 
AMR, GSM EFR, GSM PR)] 

- Supported Codec List information element = { [(SysID 1 = UMTS), (Codec Bitmap for SysID 1 = UMTS 
AMR 2)], [(SysID 2 = GSM), (Codec Bitmap for SysID 2 = FR AMR, GSM EFR, GSM FR)] } 

The Called Party Number information element identifies the intended recipient of the call, and the Bearer 
Capability information element and the Supported Codec List information element identify an intended call that 
can be subject to VCC. 

The VMSC knows the calling party number corresponding to the UE. 

3. Origination triggers 

4. CAMEL IDP (VMSC to CAMEL service function) 

On receipt of the SETUP message, the VMSC triggers a CAMEL activity which results in sending a CAMEL 
IDP message to the gsmSCF. The CAMEL IDP message contains at least: 

- the calling party number; 

service key assigned to the subscriber; 
the called party number; and 
that the call is voice only. 

5. Anchor decision 

The CAMEL service function decides that this call will be anchored, based on the type of call and operator 
preferences. 

6. CAMEL CONNECT (gsmSCF to VMSC) 

The CAMEL service function in this example causes the gsmSCF to respond to the CAMEL IDP message with a 
CAMEL CONNECT message containing: 

the Destination Routing Address set to the IMRN; 

- the Original Called Party ID; 
Redirecting Party ID; and 
Redirection Information. 

7. ISUP lAM (VMSC to MGCP) 

The VMSC initiates the CS call towards the MGCF by sending out the lAM message. 
Specifically for this signalling flow, the lAM includes: 
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Called Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12415553333)] 

Calling Party Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125551 1 1 1)] 

USI parameter = 3.1 kHz audio 

Original Called Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type 
of number = international number ), (Number digits = 12125552222)] 

Redirecting Number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number ), (Number digits = 12125552222)] 

Redirection information = [(Redirecting indicator = call diverted, all redirection info presentation 
restriceted), (Original redirection reason = unknown), (Redirection counter =1), Redirecting reason = 
unknown)] 

The Called Party Number parameter represents the IMRN allocated for this call. 

8. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.4.4-8 

The MGCF initiates a SIP INVITE request, containing an initial SDP. The MGCF in this example needs to 
support call diversion. 

Table A.4.4-8: SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 .homel .net ;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P- Asserted- Identity: <tel :+l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel : +1-212 -555- 1111> ; tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

History-Info: <tel : +l-212-555-2222>; index=l, < tel : +l-212-555-2222>; \cause=404 ; index=l.l 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



Request-URI: Contains the IMRN, as obtained from CS domain signalling. 

P-Asserted-Identity: The MGCF inserts the tel-URL containing the calling party number as received from the CS 
network. 

SDP The SDP contains a preconfigured set of codecs supported by the MGW based on what is 

received in the ISUP. The codecs selected are speech codecs, for which VCC can be applied. 
See table 10a of 3GPP TS 29.163 [10]. 
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History-Info: The MGCF inserts the original called party number and an entry for the redirecting number 

as received from the CS network. 

9. SIP INVITE request (intermediate IM CN subsystem entities to CSAF) - see example in table A.4.4-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. In 
this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF 
before the I-CSCF and no intermediate entities Record-Route the request. 

Table A.4.4-9: SIP INVITE request (intermediate IM CN subsystem entities to CSAF) 



INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip : csafl .homel .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 
3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
History-Info : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

1 1 . VCC application 

The CSAF and DTF in combination act as an initiating B2BUA. The CSAF places the original call party number 
in the Request-URI and the To header of the outgoing request and removes the History -Info header. 

12. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. In this example, the subsequent flows assume that a visit has been made to the 
S-CSCF, in association with the the triggering of initial filter criteria, in order to reach the DTF. 

13. VCC application 

The CSAF and DTF in combination act as an initiating B2BUA. The DTF anchors the call to provide VCC 
functionahty. 

14. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.4.4-14 

The DTF forwards the SIP INVITE request to the S-CSCF serving the originating user within the IM CN 
subsystem. In this case it is assumed that the user is registered within the IM CN subsystem. 
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The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer 
functionality needed to support VCC. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

Table A.4.4-14: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP dtfl.homel.net;branch=z9hG4bK312a32 .1 

Max- Forwards : 6 6 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip :dtfl .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Editor's note: Need to add "orig" parameter to above table. 

Contact header: The Contact header represents the contact of the DTF. 

15. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

16. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.4-16 

The intermediate IM CN subsystem entities route the SIP INVITE request to the terminating side. In this 
example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 
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Table A.4.4-16: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

dtf 1 .homel .net;branch=z9hG4bK312a32 . 1 
Max- Forwards : 65 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type: 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



17. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

18. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no VCC specific actions associated 
with this step. 

The DTF and CS/VF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

19. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

21. Interaction between DTF and CSAF 
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Information is exchanged between the CS AF and the DTF. The nature of this signalhng is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

22. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities) 

The CSAF forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

23. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no VCC specific content to this response. 

24. ISUP ANM (MGCF to VMSC) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM message and sends this to the 
VMSC. 

There is no VCC specific content to this response. 

25. CONNECT (VMSC to VCC UE) 

The VMSC sends a CONNECT message to the VCC UE. 
There is no VCC specific content to this response. 

26. CONNECT ACKNOWLEDGE (VCC UE to VMSC) 

The VCC UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message. 
There is no VCC specific content to this response. 

27. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

28. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

29. SIP ACK request (intermediate IM CN subsystem entities to CSAF) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the CSAF. 
There is no VCC specific content to this response. 

30. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

3L SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF forwards the SIP ACK request back to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 
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32. SIP ACK request (intermediate EM CN subsystem entities to terminating side processing) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this response. 

A.4.5 Signalling flows for origination from CS domain with no 
anchoring 

Figure A.4.5- 1 shows the origination of a voice call that is capable of being subject to VCC, with the anchoring of the 
call in the IM CN subsystem being denied prior to its routeing. The voice call is then continued in the CS domain 
according to standard procedures. 

The anchor decision of such origination calls is subject to operator policy. 

As the originating voice call is not anchored in the IM CN subsystem, domain transfer will not be supported for that 
call. 
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Figure A.4.5-1 : call origination from CS with no anchoring 

The details of the signalling flows are as follows: 

Steps 1 to 4 are identical to the example in subclause A.4.3. 

NOTE 1 : When processing the originating calls for subscriber requiring CAMEL support (step 3), the VMSC 

retrieves the originating CAMEL subscriber information from the VLR that identifies the subscriber as 
having CAMEL services. As a result the gsmSSF of the VMSC triggers a CAMEL activity toward the 
gsmSCF. 

5. Anchor decision 

The CAMEL service function denies the anchoring of the originating call according to the operator policy. In 
this example the called party number is not in the international format and the home IM CN subsystem has no 
means to translate the called party number into a proper routable format. 

6. CAMEL CONTINUE (gsmSCF to VMSC) 
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The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL 
CONTINUE message. The CAMEL CONTINUE message contains no parameter. 

NOTE 2: On the receipt of the CAMEL CONTINUE message, the VMSC resumes the processing, continues the 
call in the CS domain according to standard procedures and without any modification of the call 
parameters. 

A.4.6 Signalling flows for origination from CS domain for a user 
that is not registered within the IIVI CN subsystem 

Figure A.4.6- 1 shows the origination of a call in the CS domain that is capable of being subject to VCC when the user is 
not currently registered within the IM CN subsystem. 
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Figure A.4.6-1 : CS call origination from the VCC user that is not IMS registered 

The details of the signalling flows are as follows: 
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Steps 1 through 14 are identical to those shown in subclause A.4.3. 

15. SIP INVITE request (DTP to intermediate IM CN subsystem entities) - see example in table A.4.6-15 

In this example, the VCC user is not registered in the IM CN subsystem. The DTF forwards the SIP INVITE 
request to the intermediate IM CN subsystem entities, specifically the 1-CSCF as for AS originating procedures 
for unregistered users. The 'orig' parameter is added to the Route header. 

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer 
functionality needed to support VCC. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

NOTE: The service profile needs to be the same for the originating registered case and the originating 
unregistered case. 

Table A.4.6-15: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP dtf 1 . homel . net ;branch=z9hG4bK312a32 . 1 

Max-Forwards: 66 

Route : <sip : i-cscf . homel . net ; Ir ; orig> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip :dtfl .homel .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



Contact header: The Contact header represents the contact of the DTF. 

16. SIP 100 (Trying) response (I-CSCF to DTF) 

The I-CSCF responds to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

17. Intermediate IM CN subsystem processing (selection of S-CSCF) 

The intermediate IM CN subsystem entities (1-CSCF) will select a S-CSCF for the unregistered user. The I- 
CSCF will recognize the 'orig' parameter on the Route header and query the HSS for the originating party in P- 
Asserted-Identity header. The I-CSCF will select a S-CSCF based upon the user capabilities and the capabillities 
of the S-CSCFs as currently described in 3GPP TS 24.229 [8] subclause 5.3. The I-CSCF forwards the inrequest 
to the S-CSCF. 
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18. SIP INVITE request (intermediate IM CN subsystem entities to terminating side processing) - see 
example in table A.4.6-18 

The intermediate IM CN subsysteme entities (S-CSCF) routes the SIP INVITE request to the terminating side 
processing. In this example, there is no intermediate IBCF and none of the intermediate entities Record-Route. 

Table A.4.6-18: SIP INVITE request (intermediate IM CN subsystem entities to terminating side 

processing) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 . 0/UDP dtf 1 . homel . net 

SIP/2 . 0/UDP;branch=z9hG4bK312a32 . 1 
Max-Forwards: 64 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



19. SIP 100 (Trying) response (terminating side processing to intermediate IM CN subsystem entities) 

The terminating side processing responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

20. SIP 180 (Ringing) response, ISUP ACM and ALERTING message (terminating side processing to VCC 

UE) 

The call is successfully delivered to the terminating UE, which begins alerting the user. Normal SIP, ISUP and 
access signalling messages are transferred to indicate this is occurring. At or before this time, completion of 
negotiation of the bearer (e.g. as indicated by SDP in SIP) occurs. There is no VCC specific actions associated 
with this step. 

The DTF and CS/VF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

21. SIP 200 (OK) response (terminating side processing to intermediate IM CN subsystem entities) 

A SIP 200 (OK) response is received from the terminating side processing by the intermediate IM CN subsystem 

entities. 

There is no VCC specific content to this response. 

22. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 
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The intermediate IM CN subsystem entities forwards the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

23. Interaction between DTF and CSAF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

24. SIP 200 (OK) response (CSAF to intermediate IM CN subsystem entities) 

The CSAF forwards the SIP (200) OK response back to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

25. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no VCC specific content to this response. 

26. ISUP ANM (MGCF to VMSC) 

On receipt of the SIP 200 (OK) response, the MGCF generates an ISUP ANM and sends this to the VMSC. 
There is no VCC specific content to this response. 

27. CONNECT message (VMSC to VCC UE) 

The VMSC sends a CONNECT message to the VCC UE. 
There is no VCC specific content to this response. 

28. CONNECT ACKNOWLEDGE message (VCC UE to VMSC) 

The VCC UE generates the CONNECT ACKNOWLEDGE message on receipt of the CONNECT message. 
There is no VCC specific content to this response. 

29. SIP ACK request (MGCF to CSAF) 

The MGCF generates a SIP ACK request on receipt of the SIP 200 (OK) response and sends it back to the 
CSAF. 

There is no VCC specific content to this response. 

30. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

31. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

The DTF and CSAF modify the message in accordance with initiating B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

32. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF forwards the SIP ACK request to the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

33. SIP ACK request (intermediate IM CN subsystem entities to terminating side processing) 
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The intermediate IM CN subsystem entities forwards the SIP ACK request to the terminating side processing. 
There is no VCC specific content to this response. 

A.5 Signalling flows for call termination 
A. 5.1 Introduction 

The signalHng flows for call termination demonstrate how a terminating call to a VCC UE is anchored for the purposes 
of a future domain transfer. The following signalling flows are included: 

subclause A.5. 2 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring and subsequent delivery of the call to the terminating 
VCC UE; 

subclause A. 5. 3 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring, but subsequently rerouted the call back to the CS 
domain for delivery to the terminating VCC UE; 

subclause A.5. 4 shows a terminating call arriving at the CS domain, where CAMEL has been used to redirect the 
call to the IM CN subsystem for anchoring and subsequent delivery to the terminating VCC UE; 

subclause A. 5. 5 shows a terminating call arriving at the CS domain, getting routed to, and anchored at the IM 
CN subsystem, and subsequently routed back to the CS domain for delivery to the terminating VCC UE. The call 
routeing from the CS domain to the IM CN subsystem for anchoring is by the HSS(HLR), through internal 
network implementation, obtaining the IMRN for routeing to the IM CN subsystem; 

subclause A. 5. 6 shows a terminating call arriving at the IM CN subsystem, where incoming call routeing has 
directed the call to the IM CN subsystem for anchoring, but delivery to the terminating VCC UE in the IM CN 
subsystem has failed, and redelivery is made to the VCC UE in the CS domain; 

subclause A. 5. 7 shows a terminating call arriving at the CS domain, getting routed to, and anchored at the IM 
CN subsystem, and subsequently routed back to the CS domain for delivery to the terminating VCC UE, but 
delivery fails and redelivery is made to the VCC UE using the IM CN subsystem; and 

subclause A. 5. 8 shows a terminating call arriving at the CS domain, where CAMEL is used but for which the 
anchoring is denied; the call is continued and delivered in the CS domain. 

A. 5. 2 Signalling flows for termination to the IM CN subsystem 

Figure A.5. 2-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has 
been routed through the IM CN subsystem and where the called party is terminating in its home IM CN subsystem. 
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Figure A.5.2-1 : Terminating call directed to IM CN subsystem 

The details of the signalling flows are as follows: 

1 . SIP INVITE request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) 
see example in table A.5.2-1 

In this example the originating UE initiates a voice call through its home IM CN subsystem (homel) with a 
terminating UE which is VCC capable who is in a different network (home2). There is no specific VCC 
information in the SIP INVITE request from the originating UE. 
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The SIP INVITE request is sent by the originating IM CN subsystem to the intermediate IM CN subsystem 
entities. 

Table A.5.2-1 : SIP INVITE request (from the originating IM CN subsystem) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Route : <sip : scscf 1 . homel . net ; lr> 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+S02IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp = sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode- change -period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



2. Evaluation of initial filter criteria 

In this example, and by evaluation of the initial filter criteria, the terminating user's S-CSCF routes to the address 
of the DTP, as the received request is a terminating INVITE request. 

3. SIP INVITE request (intermediate IM CN subsystem entities to DTE) - see example in table A.5.2-3 

The terminating user's S-CSCF adds a set of routeing related headers in order to receive the SIP INVITE request 
back, to route the present request to the DTP and to maintain itself on the route for all subsequent requests. 

The intermediate IM CN subsystem entities forward the INVITE request to the DTP. 
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Table A.5.2-3: SIP INVITE request (intermediate IM CN subsystem entities to DTF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b33 .1, SIP/2. 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 66 

Route: <sip:dtf2 .home2 .net;lr>, <sip:scscf2 .home2 .net ; lr>;dia-id=6574839201 

Record- Route : <sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 .homel .net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; 
orig-ioi="type 3ashomel.net" 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



4. Session anchoring 

The DTF decides to perform session anchoring decision based on operator specified criteria. 

5. Interaction between the DTF and DSF 

Information is exchanged between the DTF and DSF. The nature of this signalHng is outside the scope of this 
version of the specification. Alternative procedures for invoking the DSF are possible, for example, further 
evaluation of filter criteria when the outgoing request from the DTF after anchoring is sent back to the S-CSCF. 

6. The DSF selects the terminating domain 

The DSF performs domain selection based on operator and user preferences, registration and call states; in this 
example the DSF selects the terminating IM CN subsystem to terminate the voice call. 

7. Interaction between the DTF and DSF 

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this 
version of the specification. 

8. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.5.2-8 

The DTF acts as a routeing B2BUA, it initiates the outgoing request and places the called party number in the 
Request-URI and the To header. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

The DTF sends the SIP INVITE request back to the intermediate IM CN subsystem entities. 
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Table A.5.2-8: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP sip:dtf2 .home2 .net; branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 

Route: <sip:scscf2 .home2 .net ; lr>;dia-id=6574839201 
Record-Route : <sip : dtf 2 . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip :pcscf 1 .homel .net ; lr> 
P-Asserted- Identity : 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



No more triggering is required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE 
request to the terminating user based on its SIP-URI. The SIP AS that implements the DSF or the combination of 
the DTF and DSF acting as a B2BUA - which performs the third-party call control - needs to be the last located 
application server to ensure that all application servers that need to remain in the path of a call after domain 
transfer will do so. 

9. SIP INVITE (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.2-10 

The terminating user's intermediate IM CN subsystem entities forward the SIP INVITE request towards the 
terminating VCC UE. 



£75/ 



3GPP TS 24.206 version 7.3.0 Release 7 57 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

Table A.5.2-10: SIP INVITE request (intermediate IM CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net :5088;comp=sigcomp;branch=z9hG4bK876tl2 .1, SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z8 7 . 1, SIP/2 . 0/UDP sip:dtf2 . home 2 . net ; 
branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 63 
Record- Route : <sip :pcscf 2 .home2 .net : 5 088 ; Ir ; comp=sigcomp> , <sip:scscf2 .home2 .net ; lr>, 

<sip : dtf 2 . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted- Identity : 
Privacy: 
Supported: 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
Supported: 
Contact : 
Allow: 

P-Called-Party-ID: 
P-Media-Authorization : 
Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (VCC UE to intermediate IM CN subsystem entities) 

The intermediate VCC UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) 
response. 

There is no VCC specific content to this response. 

11,12, 13 and 14. Reliable exchange of SDP (SIP 183 (Session Progress) response / SIP PRACK request / 
SIP 200 (OK) response / SIP 180 (Ringing) response) 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-C/^, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

15. SIP 200 (OK) response (UE to intermediate IM CN subsystem entities) 

When the called party answers, the UE sends a SIP 200 (OK) final response to the SIP INVITE request (8) to the 
intermediate IM CN subsystem entities, and starts the media flow(s) for this session. 

There is no VCC specific content to this response. 

16. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 
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17. SIP 200 (OK) response (DTF to intermediate IM CN subsystem entities) 

The DTF sends the SIP 200 (OK) response back to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

18. SIP 200 (OK) response (to originating IM CN subsystem) 

The terminating user's intermediate IM CN subsystem entities, forwards the SIP 200 (OK) final response along 
the signalling path back to the calling user through the originating IM CN subsystem. 

There is no VCC specific content to this response. 

19. SIP ACK request (from the originating IM CN subsystem) 

The calling user responds to the SIP 200 (OK) final response with an ACK request through the originating IM 
CN subsystem to the intermediate IM CN subsystem entities of the terminating user. 

There is no VCC specific content to this request. 

20. SIP ACK request (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the DTF. 
There is no VCC specific content to this request. 

21. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF sends the SIP ACK request back to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

22. SIP ACK request (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the terminating VCC UE. 
There is no VCC specific content to this request. 

A. 5. 3 Signalling flows for termination to CS domain 

Figure A.5.3-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call has 
been routed through the IM CN subsystem and where the called party is terminating in its home CS domain. 
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HPLMN of the terminating UE 




Figure A.5.3-1 : Terminating call directed to CS 

The details of the signalhng flows are as follows: 

Steps 1 to 5 are identical to the previous example in subclause A.5.2. 
6. The DSF selects the terminating domain 
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The DSF performs domain selection based on operator and user preferences, registration and call states; in this 
example the DSF selects the CS domain to terminate the voice call. 

7. Interaction between the DSF and CSAF 

The DSF in combination with the CSAF determines the CS domain Routeing Number (CSRN). 

The CSRN is a dynamic routeing number used for routeing into CS domain, i.e. to find the outgoing MGCF and 
then the terminating user's VMSC. 

The interaction between the DSF and CSAF is outside the scope of this version of the specification. 

8. Interaction between the DTE and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

9. SIP INVITE request (DTE to intermediate IM CN subsystem entities) - see example in table A.5.3-9 

Since the service execution continues as an terminating case, the DTF initiates a SIP INVITE request with the 
CSRN as the Request-URI and in the To header, and sends the SIP INVITE request back to the intermediate IM 
CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

The DTF inserts the original SDP from the originating SIP INVITE request. 

Table A.5.3-9: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP sip : dtf 2 . home2 . net ; branch=z9 jG4bK332b23 . 3 , SIP/2 . 0/UDP 

scscf2.home2.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2_s.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 65 

Route: <sip: scscf2 .home2 .net;lr>; dia-id=6574839201 
Record-Route : <sip : dtf 2 . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP INVITE request (intermediate IM CN subsystem entities to MGCE) - see example in table A.5.3-10 
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The intermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example, the 
MGCF is reached using a single BGCF. 

Table A.5.3-10: SIP INVITE request (intermediate IM CN subsystem entities to IVIGCF) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP sip : dtf 2 . home2 . net ; 
branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 63 

Route: <sip :mgcf 2 .home2 .net; lr>; 
Record-Route : <sip : scscf 2 . home2 . net ; lr> , <sip : dtf 2 . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , 

<sip : scscf 1 . homel . net ; lr> , <sip :pcscf 1 . homel . net ; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" ; term-ioi="home2 .net" 
Privacy: 
Supported: 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



1 la- 1 Id. SIP 183 (Session Progress) response / SIP PRACK request / SIP 200 (OK) response and Reliable 
exchange of SDP 

Reliable exchange of SDP is initiated using the SIP 183 (Session Progress) response and the SIP PRACK request 
and response. 

12. H.248 interaction with the IM-MGW 

When the outgoing MGCF receives a SIP INVITE request with an SDP offer it will first interact with the IM- 
MGW to pick an outgoing channel and determine media capabilities, then can proceed with further SDP 
offer/answer with the originating UE and finally will instruct IM-MGW to reserve the resources necessary for 
the media streams. 

13. ISUP lAM (MGCF to VMSC) 

The MGCF interworks the SIP INVITE request into ISUP and initiates the ISUP lAM carrying the CSRN 
towards the VMSC on which the terminating VCC UE is currently registered (for the interworking ISUP / SIP 
function see 3GPP TS 29.163 [10]). 

14. SETUP message (VMSC to terminating VCC UE) 

The VMSC can derive from the CSRN the details of the called party and then initiates a paging procedure 
towards the terminating VCC UE. 
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After the VCC UE has successfully accessed the network, the VMSC sends to the UE the SETUP message (see 
3GPP TS 24.008 [5]). There is no VCC specific information in the SETUP message. 

15. ALERTING (terminating UE to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, ALERTING is 
sent back from the UE to the VMSC. There is no VCC specific information in the ALERTING message. 

16. ISUP ACM (VMSC to MGCP) 

17a-17d. ISUP CFG, SIP 180 (Ringing) response and SIP PRACK request (end to end) 

On receipt of the ALERTING message from the terminating VCC UE, the VMSC and the MGCF exchange 
ISUP to indicate that the called party confirmed the call and did start ringing the end user. 

The VMSC starts resource allocation towards the terminating VCC UE. 

Between VMSC and the IM-MGW resource allocation is also started. 

18. CONNECT message (terminating VCC UE to VMSC) 

When the user answers the call, the terminating VCC UE sends a CONNECT message to the VMSC. After 
sending the CONNECT message, the terminating VCC UE is ready to connect to user plane resources. 

There is no VCC specific information in the CONNECT message. 

19. CONNECT_ACK message (VMSC to terminating VCC UE) 

The VMSC connects up the user plane and return CONNECT_ACK message to the terminating UE. Through 
connect all the way back to originating UE is not initiated. 

There is no VCC specific information in the CONNECT_ACK message. 

20. ISUP ANM (VMSC to MGCF) 

The VMSC having through connected the user plane sends an indication of answer to the MGCF. This is the 
ISUP ANM. 

21. H.248 interaction to start the media flow (MGCF to IM-MGW) 

MGCF initiates a H.248 interaction to make the connection in the IM-MGW bi-directional. 

22. SIP 200 (OK) final response (MGCF to intermediate IM CN subsystem entities) 

Upon the receipt of the ISUP ANM from the MSC, and after the connection of the media flow, the MGCF sends 
the SIP 200 (OK) final response to the received SIP INVITE request (6) toward the IM CN subsystem. The SIP 
200 (OK) response is sent by the MGCF on the behalf the terminating VCC UE over the signalling path to the 
terminating user's S-CSCF. 

There is no VCC specific content to this response. 

23. SIP 200 (OK) final response (from intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) final response to the DTF. 
There is no VCC specific content to this response. 

24. SIP 200 (OK) final response (from DTF to intermediate IM CN subsystem entities) 

The SIP 200 (OK) final response is sent back to the terminating user's S-CSCF by the DTF. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

25. SIP 200 (OK) final response (intermediate IM CN subsystem entities to originating IM CN subsystem) 
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The SIP 200 (OK) response is returned to the originating UE through the originating IM CN subsystem, by the 
terminating user's intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

26. SIP ACK request (from the originating IM CN subsystem to intermediate IM CN subsystem entities) 

The originating UE sends the final acknowledgement to the terminating user's IM CN subsystem through the 
originating IM CN subsystem to the intermediate IM CN subsystem entities of the terminating user. 

There is no VCC specific content to this request. 

27. SIP ACK request (intermediate IM CN subsystem entities to DTF) 

The terminating user intermediate IM CN subsystem entities forward the SIP ACK request to the DTF. 
There is no VCC specific content to this request. 

28. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF sends the SIP ACK request back to terminating user's intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

29. SIP ACK request (intermediate IM CN subsystem entities to MGCF) 

The terminating user's intermediate IM CN subsystem entities forward the SIP ACK request to the MGCF and 
that concludes the terminating call signalling. 

There is no VCC specific content to this request. 

A. 5. 4 Signalling flows for termination directed to IIVI CN 

subsystem (coming from the CS domain) (using CAIVIEL) 

Figure A.5.4-1 shows the termination of a call that is capable of being subject to VCC, where the calling party call is 
coming from CS and where the called party is terminating in its home IM CN subsystem. 

For call termination, the use of CAMEL in the context of VCC is optional. In this example the GMSC support and will 
use terminating CAMEL service logic. 
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HPLMN of the terminating UE 




Figure A.5.4-1 : Terminating call coming from CS domain (using CAMEL) 

The details of the signahing flows are as follows: 

1 . ISUP lAM (coming from the originating PLMN through the CS domain) 

In this example, a call request (ISUP lAM) makes an entry from the PLMN of the originating user (calling party) 
into the home PLMN of the terminating user (called party). The first entry point of the PLMN of the terminating 
user is the Gateway MSC (GMSC). The call request is a form of an ISUP lAM (Initial Address Message) and 
contains the called party number (MSISDN) 

In this example the MSISDN of the called party is +1-212-123.2222. 

2. MAP Send Routing Information (SRI) (GMSC to HLR) 

On receipt of the incoming call request, the GMSC queries the HLR for routing information. 

3. Retrieval of VCC subscriber information 
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The HLR provides information including the T-CSI information element that contains information configured 
for the VCC subscriber, identifying the subscriber as having terminating CAMEL services. The T-CSI IE also 
includes the gsmSCF address. 

4. MAP Send Routing Information Acknowledgement (SRI ACK) (HLR to GMSC) 

The HLR returns the T-CSI information element to the GMSC in response to the query for routing information 
(SRI). The GMSC now has the address of the gsmSCF. 

5. CAMEL IDP (GMSC to gsmSCF) 

The GMSC triggers a CAMEL activity which results in sending a CAMEL IDP message to the GSM Service 
Control Function (gsmSCF). The CAMEL IDP message contains at least: 

- the calling party number; 
the called parting number; 
the type of call; and 

- information from the T-CSI IE received by the GMSC in the SRI ACK from the HLR. This includes the 
CAMEL service key. 

NOTE: The CAMEL service key can be shared among different CAMEL services, for example, if a VCC 
subscriber is also a prepaid customer. 

6. Reroute to IMS determination 

The gsmSCF invokes service logic to determine whether the call needs to be rerouted to IM CN subsystem for 
VCC. 

7. Interaction between CAMEL service and CSAF 

Communication is required between the CAMEL service function and the CSAF in order to ensure that the 
nature of the call associated with the IMRN is known by the CSAF. The signalling to support this 
communication is not specified in this version of the specification. 

8. CAMEL CONNECT (gsmSCF to GMSC) 

The gsmSCF to respond to the CAMEL IDP message with a CAMEL CONNECT message containing: 
the Destination Routeing Address set to the IMRN. 
The IMRN is subsequently used to route the call to the VCC application though the IM CN subsystem. 

9. ISUP lAM (GMSC to MGCF) 

The GMSC initiates the CS call towards the MGCF by sending out the ISUP lAM. 

Specifically for this signalling flow, the lAM includes: 

called party number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 12415553333)] 

calling party number parameter = [(Numbering plan identifier = ISDN/telephony numbering plan), (type of 
number = international number), (Number digits = 1212555 11 1 1)] 

USI parameter = 3.1 kHz audio 

The called party number parameter represents the IMRN allocated for this call. 

10. H.248 interaction with the IM-MGW 

When the MGCF receives the incoming call from the CS domain it will first interact with the IM-MGW to 
reserve the resources necessary for the media streams and determines the SDP parameter of the outgoing SIP 
INVITE request. 
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1 1. SIP INVITE request (MGCF to intermediate IM CN subsystem entities) - see example in table A.5.4-11 

The MGCF initiates a SIP INVITE request, containing an initial SDP towards the I-CSCF in the home IM CN 
subsystem of the terminating VCC user. This routeing is based on the IMRN. 

The Request-URI contains the IMRN, as obtained from CS networks signalling. 

The P-Asserted-Identity contains the tel URI of the calling party as received from the CS network. 

Based on what is received in the ISUP, the MGCF identifies the incoming call as speech call and includes in the 
SDP a preconfigured set of codecs supported by the MGW (for more details see 3GPP TS 29.163 [10]). 

Table A.5.4-11 : SIP INVITE request (MGCF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf2 .homel.net;branch=z9hG4bK779s24 . 

Max- Forwards : 70 

Route : <sip : icscf 2 . home2 . net ; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="homel .net" 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: 10 Orel 

Contact: <sip :mgcf 2 .home2 .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; mode-change-period=2 

a = r tpmap :96 telephone- event 

a=maxpt ime : 2 



12. SIP INVITE request (intermediate IM CN subsystem entities to DTE) - see example in table A.5.4-12 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route requests to this PSI to 
the DTF. The SIP INVITE request is therefore forwarded to the DTF. 
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Table A.5.4-12: SIP INVITE request (intermediate IM CN subsystem entities to DTF) 



INVITE tel:+l-212-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf2 .home2 .net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 69 
Route: <sip :dtf 2 .home2 .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 
3homel .net" ; orig-ioi="homel .net" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



13. SIP 100 (Trying) response (DTF to intermediate IM CN subsystem entities) 

There is no VCC specific content to this response. 

14. Session anchoring 

In this example, the DTF decides here that this call will be anchored, based on the type of call and operator 
preferences. 

15. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

16. Domain selection 

The CS/VF retrieves the original called party number and calling party number associated with the IMRN and 
DSF performs domain selection based on operator and user preferences, registration and call states; in this 
example the DSF selects the IM CN subsystem to terminate the call. 

17. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

The DTF acts as a routeing B2BUA, thus it initiates the outgoing request and places the called party number in 
the Request-URI and the To header. 

After this step, the IMRN associated with this session is available for reuse. 

18. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.5.4-18 

The DTF forwards the SIP INVITE request to the S-CSCF serving the terminating user within the IM CN 

subsystem. 
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The DTF modifies the message in accordance with routeing B2BUA fiinctionahty, e.g. mapping of From, To, 
Cseq and Call-ID headers fi^om one side of the B2BUA to the other. 

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer 
functionality needed to support VCC. 

In the case where the Request-URI of the SIP INVITE request contains a tel-URL, the S-CSCF (next hop) will 
have to translate to a globally routeable SIP-URI before applying it as Request-URI of the outgoing SIP INVITE 
request toward the terminating user. 

Table A.5.4-18: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP dtf2.home2.net; branch=z9hG4bK779s24 . , SIP/2 . 0/UDP 
mgcf2.home2.net;branch=z9hG4bK779s24 . 0, SIP/2 . 0/UDP 
icscf2 .home2 .net ;branch=z9hG4bK312a32 . 1 
Max- Forwards : 6 8 

Route : <sip : s-cscf . home2 . net ; lr> 
P-Asserted- Identity : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; 

orig-ioi="Type 3homel.net" 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltl0b3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip :dtf 2 .home2 .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



19. Evaluation of initial filter criteria 

In this example, the S-CSCF continues the triggering from the next trigger point. Since no more triggering is 
required in the initial filter criteria, the IM CN subsystem will route the SIP INVITE request to the terminating 
user based on its SIP URL 

20. SIP INVITE request (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.4-20 

The terminating user's intermediate IM CN subsystem entities forward the SIP INVITE request towards the 
terminating VCC UE. 
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Table A.5.4-20: SIP INVITE request (intermediate IM CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2 .home2 .net :5088;comp=sigcomp;branch=z9hG4bK876tl2 .1, SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z8 7 . 1, SIP/2 . 0/UDP sip:dtf2 . home 2 . net ; 
branch=z9 jG4bK332b23 . 3 , SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
icscf2.home2.net;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 
mgcf2 .home2 .net ;branch=z9hG4bK332b23 . 1, 

Max- Forwards : 6 7 

Record-Route : 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Allow: 

P-Called-Party-ID: 

P-Media-Authorization : 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



21. SIP 100 (Trying) response (VCC UE to intermediate IM CN subsystem entities) 

The VCC UE responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

22. Reliable exchange of SDP and Ringing/Alerting signalling 

The terminating UE accepts the session request and reserves an IP-CAN bearer for the message session media 
component. 

SDP offer/answer exchange can happen between the called party and the MGCP. 

End users signals end to end ringing/alerting 

23. SIP 200 (OK) response (UE to intermediate IM CN subsystem entities) 

When the called party answers, the UE sends a SIP 200 (OK) final response to the SIP INVITE request (16) to 
the intermediate IM CN subsystem entities, and starts the media flow(s) for this session. 

There is no VCC specific content to this response. 

24. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTE) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

25. SIP 200 (OK) response (DTE to intermediate IM CN subsystem entities) 

The DTF sends the SIP 200 (OK) response back to the intermediate IM CN subsystem entities. 
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The DTF modifies the message in accordance with routeing B2BUA fiinctionahty, e.g. mapping of From, To, 
Cseq and Call-ID headers fi^om one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

26. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The terminating user's intermediate IM CN subsystem entities forward the SIP 200 (OK) final response to the 
MGCF. 

There is no VCC specific content to this response. 

27. ISUP ANM (MGCF to GMSC) 

The MGCF indicates the call has been answered back to the GMSC with an ISUP ANM. 
There is no VCC specific content in this message. 

28. ISUP ANM (GMSC to the originating user's PLMN) 

The GMSC forwards the ISUP ANM to the originating user's PLMN. 
There is no VCC specific content in this message. 

29. SIP ACK request (MGCF to intermediate IM CN subsystem entities) 

Having indicated the call has been answered toward the originating user, the MGCF acknowledges the SIP 200 
(OK) response with the SIP ACK request to the intermediate IM CN subsystem entities. 

There is no VCC specific content to this request. 

30. H.248 interaction to start the media flow (MGCF) 

MGCF initiates a H.248 interaction to make the connection in the IM-MGW bi-directional. 

31. SIP ACK request (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the DTF. 
There is no VCC specific content to this request. 

32. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The DTF sends the SIP ACK request back to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

33. SIP ACK request (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the VCC UE. 
There is no VCC specific content to this request. 

A. 5. 5 Signalling flow for termination directed to CS domain 
(coming from the CS domain) 

Figure A.5.5-1 illustrate an example signalling flow of a voice call to a VCC UE coming in through the CS domain, 
getting anchored to the VCC application within the IM subsystem and then delivered to the terminating VCC UE 
through the CS domain. 

In this example, the terminating UE is in his/her HPLMN. 
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In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates 
HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network 
implementation, can obtain the IMRN. 
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Figure A.5.5-1 : Terminating call coming in through CS domain and delivered through the CS domain 
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Figure A.5.5-1 : Terminating call coming in through CS domain and delivered through the CS domain (continued) 
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The details of the signalling flows are as follows: 

1 . ISUP lAM (coming into this PLMN through the CS domain) 

A call request makes an entry into this PLMN. First entry point is the GMSC. 
This Initial Address Message contains the MSISDN of the called party 
In this example the MSISDN is +1-212-123.2222. 

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR) 

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call 

request. 

This GMSC query SEND_ROUTING_INFORMATION contain the MSISDN of the called party. 

3. Derivation of IMRN 

Internal network actions - not indicated here as those actions are implementation and network dependent - are 
taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN 

subsystem. 

In particular an IMRN is obtained in these internal network actions. 

For this example the derived IMRN is +1-212-123-3333. 

NOTE 1 : It is an implementation and network option whether the derivation of the IMRN takes in the decision to 
anchor the call to the DTF. 

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC) 

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT 
providing with it the IMRN 

5. ISUP lAM (GMSC to MGCFa) 

GMSC sends out lAM (IMRN). The IMRN is that which will direct the routeing of the lAM to the MGCF. 
In this example, the lAM (IMRN = +1-241-555-3333) is routed to MGCFa. 

6. SIP INVITE request (MGCFa towards the CSAF through the intermediate IM CN subsystem entities) - 
see example in table A.5.5-6 

The MGCF interworks the lAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE request 
towards the CSAF via the intermediate IM CN subsystem entities. 



£75/ 



3GPP TS 24.206 version 7.3.0 Release 7 75 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

Table A.5.5-6: SIP INVITE request (MGCFa towards the CSAF through the intermediate IM CN 

subsystem entities) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: 10 Orel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



7. H.248 interaction witli the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

8. SIP 100 (Trying) response (intermediate IM CN subsystem entities to MGCFa) 

The intermediate IM CN subsystem entities respond to the MGCFa with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

9. SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) - see example in table A.5.5-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. In 
this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF 
before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.5.5-9: SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 0, SIP/2. 0/UDP 

icscf l_s .homel .net ;branch=z9hG4bK312a32 . 1 
Max-Forwards: 69 
Route: <sip : as .homel .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=type 
3homel.net; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities) 

The CSAF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

1 1 . Retrieval of the called party details from IMRN 

From the IMRN the CSAF retrieves the called party details. This retrieval process is implementation dependent. 

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC 
feature can be made available to the called party is made at this step. 

12. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and DTF. The nature of this signalling is outside the scope of this 
version of the specification. 

13. Anchoring 

The DTF performs the anchoring of the session. 

14. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

15. Domain selection 

A decision has now to be made on which domain the terminating call is to be delivered. This decision is 
implementation specific. 

For this example, the decision is to deliver the terminating call through the CS domain. 

16. Derivation of the CSRN 
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Having made the decision of delivering the call (for this example) in the CS domain, the DSF derives the CSRN. 
The CSRN will allow the call to be routed further into the CS domain. The derivation of the CSRN is 
implementation specific. 

For this example, the CSRN = +1-241-555-4444 

17. Interaction between DTF and DSF 

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this 
version of the specification. 

18. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.5.5-18 

Having derived the CSRN, the DTF now acts a routeing B2BUA and initiates a SIP INVITE request with the 
CSRN as the Request-URI. The SIP INVITE request is sent back to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

Table A.5.5-18: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max- Forwards : 6 8 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+S02IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltl0b3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip :dtf 2 .home2 .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



19. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

20. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb) 

The intermediate IM CN subsystem delivers the SIP INVITE request to the MGCF. In this example this is a 
different MCGF than the MGCF which receives the IS UP lAM carrying the IMRN. In this example the SIP 
INVITE request with the CSRN is directed to MGCFb. 

This example signalling flow involving different MGCF further illustrates a pragmatic example of call 
distribution to different MGCFs of one network. 

21. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities) 
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The MGCF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

22. ISUP lAM (MGCFb to VMSC) 

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP lAM carrying the CSRN 
towards the VMSC. 

23. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

24. Retrieval of the called party details from CSRN 

The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure 
towards the terminating UE. 

25. SETUP message (VMSC to terminating VCC UE) 

After the UE has successfully accessed the network, the VMSC sends to the VCC UE the 24.008 SETUP 
message. 

There is no VCC specific content in this message. 

For this example, the VMSC allows early local alerting. 

26. CALL_CONFIRM message (Terminating VCC UE to VMSC) 

The terminating UE acknowledges and confirms acceptance of the incoming call by sending a CONFIRM back 
to the VMSC. There is no VCC specific content in this message. 

27. ALERTING message (terminating VCC UE to VMSC) 

For this example, the VMSC allows early local alerting. With the generation of local alerting, an ALERTING 
message is sent back from the VCC UE to the VMSC. There is no VCC specific content in this message. 

28. ACM, CFG, SIP 180 (Ringing) response and SIP PRACK request (VMSC to MGCFb through IM CN 
subsystem to the originating end) 

On receipt of the ALERTING message from the terminating VCC UE, the VMSC, MGCF, IM CN subsystem 
and the originating UE exchange ISUP and SIP signalling to indicate that the called party confirmed the call and 
did start ringing the end user. 

29. Resource allocation (MSC to terminating VCC UE and VMSC) 

The VMSC starts resource allocation towards the terminating VCC UE. 

30. Resource allocation (VMSC to MGWb) 

Between VMSC and the IM-MGW resource allocation is also started. 

31. CONNECT message (terminating VCC UE to VMSC) 

When the user answers the call, the terminating VCC UE sends a CONNECT message to the VMSC. After 
sending the CONNECT message, the terminating VCC UE is ready to connect to user plane resources. 

There is no VCC specific content in this message. 

32. CONNECT_ACK message (VMSC to terminating VCC UE) 

VMSC connects up the user plane and return a CONNECT_ACKNOWLEDGE message to the terminating VCC 
UE. 

There is no VCC specific content in this message. 

Through connect all the way back to originating UE is not initiated. 
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33. ISUP ANM (VMSC to MGCFb) 

The VMSC having through connected the user plane sends an indication of answer to the MGCFTj. This is the 
ISUP ANM. 

There is no VCC specific content in this message. 

34. SIP 200 (OK) response (MGCFb to intermediate IM CN subsystem entities meant for DTF) 

Upon the receipt of the ANM from the VMSC, and after the connection of the media flow, the MGCFb sends the 
SIP 200 (OK) final response to the received SIP INVITE request ( in step 15) back to the DTF via the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

35. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The SIP 200 (OK) final response is forwarded to the VCC application, by the intermediate IM CN subsystem 
entities. 

There is no VCC specific content to this response. 

36. SIP 200 (OK) response (DTF to intermediate IM CN subsystem entities meant for MGCFa) 

The DTF sends the SIP 200 (OK) final response back to the MGCFa relating to the received SIP INVITE request 
( in step 8). This is sent through the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 

37. SIP 200 (OK) response (intermediate IM CN subsystem entities delivering to MGCFa) 

The SIP 200 (OK) final response is forwarded to the MGCFa by the intermediate IM CN subsystem entities. 
There is no VCC specific content to this response. 

38. ISUP ANM (MGCFa to GMSC) 

The MGCF indicates call has been answered back to the GMSC with ISUP ANM. 
There is no VCC specific content in this message. 

39. SIP ACK request (MGCFa to intermediate IM CN subsystem entities meant for DTF) 

Having indicate the call has been answered to the GMSC, MGCFa acknowledges the SIP 200 (OK) response 
with the SIP ACK request to the DTF. This is sent through the intermediate IM CN subsystem entities. 

There is no VCC specific content to this request. 

40. ISUP ANM (GMSC towards originating end) 

GMSC sends an indication of call answer towards the originating side. 

41. SIP ACK request (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities deliver the SIP ACK request to the DTF. 
There is no VCC specific content to this request. 

42. SIP ACK request (DTF to intermediate IM CN subsystem entities meant for MGCFb) 

DTF in turn acknowledges the MGCFt with the SIP ACK request. This is sent through the intermediate IM CN 
subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 



£75/ 



3GPP TS 24.206 version 7.3.0 Release 7 



80 



ETSI TS 124 206 V7.3.0 (2007-10) 



There is no VCC specific content to this request. 
43. SIP ACK request (intermediate IM CN subsystem entities to MGCFb) 

The SIP ACK request is delivered to the MGCFTj by the intermediate IM CN subsystem entities. 
There is no VCC specific content to this request. 

A. 5. 6 Signalling flows with call termination delivery attempt failure 
to the IIVI CN subsystem 

Figure A.5.6-1 shows the termination of a call that is capable of being subject to VCC, where the call delivery attempt 
to the IM CN subsystem fails. In this example and following information available at the VCC application, the call 
termination is re-attempted on the CS domain, 2°'' domain available. 

In this example, when the VCC Application receives the indication that delivery of the terminating call through the 
selected IM CN subsystem cannot be completed, the VCC application performs an implementation option to attempt 
delivery of the terminating call through the CS domain. Use of this implementation option depends on operator policies. 
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Intermediate IM CN 
subsystem entities 



-1. SIP INVITE 



2. Initial Filter 
Criteria 



-3. SIP INVITE 



-8. SIP INVITE 



9. User 
unreachable 
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Terminating UE 
(VCC UE) 



The termination of the call can proceed toward the CS domain as described in "A. 5. 3. Signalling flows for termination of the CS domain" starting from 

step 10. 



Figure A.5.6-1 : Call termination delivery attempt failure to the IM CN subsystem 

The details of the signalling flows are as follows: 
Steps 1 to 8 are identical to the example in subclause A. 5. 2. 
9. User unreachable 
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The delivery of the call fails due to an error detected in the termination procedure. This could be due to, for 
example, destination busy (error code 486), destination service denied (error code 403), destination currently out 
of coverage (error code 480), or some other error. In this example the intermediate IM CN subsystem returns SIP 
480 (Temporarily unavailable) response to the DTF. 

10. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to DTF) - see 
example in table A.5.6-10 

The intermediate IM CN subsystem returns SIP 480 (Temporarily Unavailable) response to the DTF. 

Table A.5.6-10: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities 

to DTF) 



SIP/2.0 480 Temporarily unavailable 




Via: SIP/2. 0/UDP sip: dtf2.home2.net; branch=z9jG4bK332b23 . 3 


SIP/2. 0/UDP 


scscf2 .home2 .net ;branch=z9hG4bK332b23 . 1, pcscf2 .home2 


net;branch=z9hG4bK431h23.1, 


SIP/2. 0/UDP 




From: 




To: 




Call-ID: 




Cseq: 




Retry-After: 3600 




Content-Length: 





1 1. Interaction between the DTF and DSF 

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this 
version of the specification. 

12. Domain Selection (re-attempt) 

In this example the VCC user has been simultaneously registered in IM CN subsystem and in the CS domain 
(CS attached). This information is known to the DSF, and after the first attempt and failure to deliver the 
terminated call in the IM CN subsystem, the DSF re-attempts on the second domain available to the terminated 
user i.e. the CS domain. 

NOTE 1 ; The choice for the DSF to re-attempt the call termination on the second domain available following a 
failure on the first domain is subject to operator policy. 

The DSF determines the CSRN. The CSRN will allow the call to be routed further into the CS domain. In this 
example the CSRN = h-1-241-555-4444 

NOTE 2: it is an implementation option as how the DSF determines the CSRN. The DSF may collaborate with the 
CS AF for determination of the CSRN. 

13. Interaction between the DTF and DSF 

Information is exchanged between the DTF and DSF. The nature of this signalling is outside the scope of this 
version of the specification. 

14. SIP INVITE request (DTF to intermediate IM CN subsystem entities) - see example in table A.5.6-12 

The DTF sends SIP INVITE request with the CSRN as the Request-URI to the intermediate IM CN subsystem 
entities. 

The DTF modifies the message received in step 3 in accordance with routeing B2BUA functionality, e.g. 
mapping of From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

The DTF inserts the original SDP from the originating SIP INVITE request. 

The History-Info header can be included to contain the public user identity of the terminating user which was 
previously included in the Request-URI. 
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Table A.5.6-14: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2. 0/UDP sip:dtf2 .home2 .net; branch=z9jG4bK332b23 . 3 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2_s.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscfl.homel.net;branch=z9hG4bK431h23 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 65 

Route: <sip: scscf2 .home2 .net;lr>; dia-id=6574839201 
Record-Route : <sip : dtf 2 . home2 . net ; lr> , <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip :pcscf 1 .homel .net; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: histinfo 
From: 

To: <tel:+l-241-555-4444> 
Call-ID: 
Cseq: 
Contact : 

History-Info: <sip: user2 publicl®home2 .net >; index=l, <tel:+ l-241-555-4444>; index=l.l 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
ra= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



The termination of the call can proceed toward the CS domain as described in the subclause A.5.3 starting from the 
step 10. 

A.5.7 Signalling flow for termination directed to CS domain, 
unsuccessful delivery, redirect to IIVI CN Subsystem 

Figure A.5.7-1 illustrate an example signalling flow of a voice call to a VCC UE coming in through the CS domain. 
Upon being anchored in the IM CN subsystem the decision on domain selection resulted in the CS domain being the 
selected domain for call delivery. However, the terminating call cannot be completed and in this example flow the 
domain selection function of the VCC application is consulted again. The IM CN subsystem is subsequently selected to 
complete the terminating call. 

In this example, the terminating UE is in his/her HPLMN. 

In this example, this PLMN does not utilise terminating CAMEL service logic. Rather this example illustrates 
HSS(HLR) directed call diversion to the IM CN subsystem where the HSS(HLR), through internal network 
implementation, can obtain the IMRN 

In this example, the failure to complete the terminating call establishment is due to the VMSC having initiated the 
paging procedure fails to get a respond from the UE in the course of normal and extended paging. 

In this example, when the MSC fails to complete the terminating call establishment, the MSC shall return the ISUP 
RELEASE message with an appropriate cause value to the MGCF that will allow the MGCF to map to an appropriate 
SIP method and indication that indicates that the user is currently not reachable. 
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Editor's note: It is FFS what cause value the ISUP RELEASE shall carry. It is also FFS which exact SIP 4xx 
message MGCP shall send. 

Editor's note: The determination of the ISUP RELEASE cause values and which SIP 4xx message MGCF sends can 
require changes to TS 29.163 

In this example, when the VCC Application receives the indication that deUvery of the terminating call through the 
selected CS domain cannot be completed, the VCC application performs an implementation option to attempt delivery 
of the terminating call through the IM CN Subsystem. This implementation option further interacts with operator 
dependent policies. 
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Figure A.5.7-1 : Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call 

delivery reselected 
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Figure A.5.7-1 : Terminating call coming in through CS domain, CS domain selected for call delivery, call delivery unsuccessful, domain for call 

delivery reselected (continued) 
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The details of the signalling flows are as follows: 

1 . ISUP lAM (coming into this PLMN through the CS domain) 

A call request makes an entry into this PLMN. First entry point is the GMSC. This ISUP lAM contains the 
MSISDN of the called party. 

In this example the MSISDN is +1-212-123-2222. 

2. MAP SEND_ROUTING_INFORMATION (GMSC to HSS/HLR) 

GMSC makes a query to the HSS/HLR for routeing information for onward routeing of the incoming call 
request. This GMSC query SEND_ROUTING_INFORMATION contain the MSISDN of the called party. 

3. Derivation of IMRN 

Internal network actions - not indicated here as those actions are implementation and network dependent - are 
taken. The result is that (for this example) a decision is make to route the call further onwards into the IM CN 

subsystem. 

In particular an IMRN is obtained in these internal network actions. 

For this example the derived IMRN is +1-241-555-3333. 

NOTE 1 : It is an implementation and network option whether the derivation of the IMRN takes in the decision to 
anchor the call to the DTF. 

4. MAP SEND_ROUTING_INFORMATION_RESULT (HSS/HLR to GMSC) 

The HSS/HLR replies to the query by GMSC with the SEND_ROUTING_INFORMATION_RESULT 
providing with it the IMRN 

5. ISUP lAM (GMSC to MGCFa) 

GMSC sends out lAM (IMRN). The IMRN is that which will direct the routeing of the lAM to the MGCF. In 
this example, the lAM (IMRN = +1-241-555-3333) is routed to MGCFa. 

6. SIP INVITE (MGCFa towards the CSAF through the intermediate IM CN subsystem) - see example in 
table A.5.7-6 

The MGCF interworks the lAM (IMRN) into the appropriate SIP message and initiates the SIP INVITE towards 
the CSAF via the intermediate IM CN subsystem entities. 

The MGCF interacts with the MGW for the necessary resource allocation. 
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Table A.5.7-6: INVITE request 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcfl.homel.net;branch=z9hG4bK779s24 . 

Max-Forwards: 70 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel:+l-212-5 55-llll>;tag=17182 8 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



7. H.248 interaction with the MGW 

The MGCF interacts with the MGW for the necessary resource allocation. 

8. SIP 100 (Trying) response (Intermediate IM CN subsystem entities to MGCFa) 

The intermediate IM CN subsystem entities respond to MGCFa with a SIP 100 (Trying) response. 
There is no VCC specific content to this request. 

9. SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) - see example in table A.5.7-9 

The IMRN is a PSI. The intermediate IM CN subsystem entities are configured to route this PSI to the CSAF. In 
this particular case, the I-CSCF performs the routeing over the Ma interface. For this example, there is no IBCF 
before the I-CSCF and no intermediate entities Record-Route the request. 
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Table A.5.7-9: SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) 



INVITE tel:+l-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP icscfl_s.homel.net;branch=z9hG4bK312a32 .1, 

SIP/2 . 0/UDP mgcf 1 .homel .net;branch=z9hG4bK779s24 . 

Max- Forwards : 69 

Route : <sip : icscf l_s . homel . net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To: <tel:+l-212-555-3333> 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Supported: lOOrel 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 2 



10. SIP 100 (Trying) response (CSAF to intermediate IM CN subsystem entities) 

The CSAF responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 

1 1 . Retrieval of the called party details from IMRN 

From the IMRN the CSAF retrieves the called party details. This retrieval process is implementation dependent. 

NOTE 2: It is a further implementation dependent option whether the decision to anchor the call such that VCC 
feature can be made available to the called party is made at this step. 

12. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and DTF. The nature of this signalling is outside the scope of this 
version of the specification. 

13. Anchoring 

The DTF performs the anchoring of the session. 

14. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

15. Domain selection 

A decision has now to be made on which domain the terminating call is to be delivered. This decision is 
implementation specific. 

For this example, the decision is to deliver the terminating call through the CS domain. 

16. Derivation of the CSRN 
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Having made the decision of delivering the call (for this example) in the CS domain, the DSF derives the CSRN. 
The CSRN will allow the call to be routed further into the CS domain. The derivation of the CSRN is 
implementation specific. 

For this example, the CSRN = +1-241-555-4444 

17. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

18. SIP INVITE (DTF towards the MGCFb through the intermediate IM CN subsystem entities) - see 
example in table A.5.7-14 

Having derived the CSRN, the DTF now acts a B2BUA and initiates an INVITE with the CSRN as the request 
URI, and sends it back to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

Table A.5.7-14: INVITE request 



INVITE tel:+l-241-555-4444 SIP/2.0 

Via: SIP/2 . 0/UDP;branch=z9hG4bK312a32 .1 

Max-Forwards: 68 

Route : <sip : s-cscf . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=Type 

3homel .net 
Privacy: 
From: 

To: <tel:+l-212-555-2222> 
Call-ID: dcl4bltlOb3teghmlk501444 
Cseq: 

Supported: 

Contact: <sip :dtf 2 .home2 .net> 
Allow: 

Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



19. Evaluation of initial Filter Criteria 

In this example there are no further matches of Service Point Triggers that cause further routeing to other 
Application Server. 

20. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

21. SIP INVITE request (intermediate IM CN subsystem entities to MGCFb) 
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The intermediate IM CN subsystem entities deliver the SIP INVITE request to the MGCF. In this example this is 
a different MCGF than the the MGCF which receives the ISUP lAM carrying the IMRN. In this example the SIP 
INVITE request with the CSRN is directed to MGCFb. 

This example flow involving different MGCF further illustrates a pragmatic example of call distribution to 
different MGCFs of one network. 

22. SIP 100 (Trying) response (MGCFb to intermediate IM CN subsystem entities) 

The MGCFb responds to the intermediate IM CN subsystem entities with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

23. ISUP lAM (MGCFb to VMSC) 

The MGCF interworks the SIP INVITE request to the ISUP and initiates the ISUP lAM carrying the CSRN 
towai-ds the VMSC. 

24. H.248 interaction with the MOW 

The MGCF interacts with the MGW for the necessary resource allocation. 

25. Retrieval of the called party details from CSRN 

The VMSC can from the CSRN retrieve the details of the called party and with that initiates a paging procedure 
towards the terminating UE. 

26. ISUP ACM (VMSC to MGCFb) 

With the determination that the address is complete and that the terminating UE details are valid the VMSC 
returns to the MGCF the ISUP ACM message. There is no VCC specific content in this message. 

27 a -f Propagation of indication of address complete back to calling side 

The SIP endpoints complete SDP offer/answer procedures, and any exchange of alerting indication, in 
accordance with standard basic call procedures. VCC imposes no restriction on this operation. 

MGCFa then sends the ISUP ACM back to the originating side through the GMSC. 

28. VMSC concludes that terminating call attempt has failed 

MSC conclude that paging procedure has failed when mobile did not respond to normal or extended paging. 

29. ISUP REL (VMSC to MGCFb) 

VMSC concluding that terminating call is unsuccessful, provides a ISUP REL to the MGCFb. The ISUP REL 
will carry the reason for release indicating that the terminating call attempt is unsuccessful. 

Editor's note: It is FFS what the exact cause the ISUP RELEASE shall carry. 

30. H.248 interaction for bearer release 

MGCFb interacts with MGWb to release the allocated resources which will now not be needed. 

31. ISUP RLC COM (MGCFb to VMSC) 

MGCFb having interacted with MGWb to release the resources return ISUP RLC COM to indicate that the 
MGCFb has now completed its release. 

32. SIP 4xx (MGCFb towards DTF through the intermediate IM CN subsystem entities) 

MGCFb indicate the release back towards the originator - in this case the DTF. This the MGCFb does by 
interworking the ISUP message to a SIP 4xx response sent to the intermediate IM CN subsystem entities. 

Editor's note: It is FFS what the exact 4xx message the MGCF will send. 

33. SIP 4xx (Intermediate IM CN subsystem to DTF) 
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The SIP 4xx is forwarded to the VCC application by the intermediate IM CN subsystem entities. 

34. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

35. DSF determines next cause of action 

In this example, the DSF decides to re-attempt delivery of the terminating call in the IM CN subsystem. This 
implementation option is further driven by an operator policy that will influence the decision of whether to re- 
attempt delivering the terminating call and limit the number of re-attempts to guard against unnecessary and 
endless looping. 

36. Interaction between the DTF and DSF 

In this example, information is exchanged between the DTF and DSF. The nature of this signalling is outside the 
scope of this version of the specification. 

37. SIP INVITE request (DTF to terminating UE through the intermediate IM CN subsystem entities) - see 
example in table A.5.7-37 

The DTF sends the SIP INVITE request to the intermediate IM CN subsystem entities serving the terminating 
user within the IM CN subsystem. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

The DTF sets the value of the Contact header with the address of the DTF that will provide the transfer 
functionahty needed to support VCC. 

The DTF sets the value of the Route header with SIP URI of S-CSCF including the original dialog identifier. 

In the case where the Request-URI of the SIP INVITE request contains a tel-URL, the S-CSCF (next hop) will 
have to translate to a globally routeable SIP-URI before applying it as Request-URI of the outgoing SIP INVITE 
request toward the terminating user. 



£75/ 



3GPP TS 24.206 version 7.3.0 Release 7 92 ETSI TS 1 24 206 V7.3.0 (2007-1 0) 

Table A.5.7-37: SIP INVITE request (DTF to intermediate IM CN subsystem entities) 



INVITE tel:+l-212-555-2222 SIP/2.0 
Via: SIP/2. 0/UDP dtf2.home2.net 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 70 

Route : <sip :o-id®s-cscf .homel .net; lr> 
Record-Route : <sip : dtf 2 . home2 . net ; lr> 

P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Inf o : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa :bbb : ccc : ddd] : 1357 ; comp = sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



Contact header: The Contact header represents the contact of the DTF. 

38. Evaluation of initial filter criteria 

To the S-CSCF that is managing the terminating UE, this will be seen as a new call, the first INVITE to the 
terminating UE. 

NOTE 3: As part of its filter criteria, care is now taken that this SIP INVITE request will not be routed back to the 
DTF for anchoring decision. Thus the S-CSCF can know that this SIP INVITE request must not be sent 
back to the DTF thanks to the original dialog identifier that has been newly included in the request. 

39. SIP 100 (Trying) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities respond to the DTF with a SIP 100 (Trying) response. 
There is no VCC specific content in this response. 

40. SIP INVITE (intermediate IM CN subsystem entities to VCC UE) - see example in table A.5.7-40 

The terminating user's intermediate IM CN subsystem entities will send the SIP INVITE request towards the 
terminating VCC UE. 
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Table A.5.7-34: SIP INVITE request (intermediate IIUI CN subsystem entities to VCC UE) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2 . 0/UDP pcscf 1 .homel .net : 5088 ; comp=sigcomp;branch=z9hG4bK8 76tl2 . 1, 

SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK764z87.1, 

SIP/2. 0/UDP sip:dtf2 .home2 .net; branch=z9jG4bK332b23 . 3 
Max- Forwards : 6 8 
Route : 

Record-Route: < pcscf 1 .homel .net>, < scscfl .homel .net>, <sip :dtf 2 .home2 .net ; lr> 
P-Asserted-Identity: "John Doe" <tel : +l-212-555-llll> 
P-Access-Network-Info : 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi="type 

3ashomel .net" 
Privacy: none 
Supported: precondition 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To: <tel:+l-212-555-2222> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



41. Signalling flows completing SIP call to terminating UE and interworked back to originating side 

The signalling flows here on till the completion of the call and utilisation of the media resources are in accordance with 
step 21 through to step 33 of subclause A.5.4, and Figure A. 5.4-1. 

A. 5. 8 Signalling flows for termination from CS domain with no 
anchoring (using CAIVIEL) 

Figure A.5.8-1 shows the termination of a voice call that is capable of being subject to VCC, with the anchoring of the 
call in the IM CN subsystem being denied prior to its routeing. The voice call is then delivered in the CS domain 
according to standard procedures. 

The anchor decision of such terminated calls is subject to operator policy. 

As the terminated voice call is not anchored in the IM CN subsystem, domain transfer will not be supported for that 
call. 

NOTE 1 : For call termination, the use of C/VMEL in the context of VCC is optional. In this example the GMSC 
support and will use terminating C/VMEL service logic. 
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the call is continued and delivered in the OS domain according to standard procedures. 



Figure A.5.8-1 : call termination from CS domain with no anchoring 

The details of the signalhng flows are as follows: 

Steps 1, 2, 3, 4 and 5 are identical to the example in subclause A.5.4. 

NOTE 2: When processing terminating calls, the GMSC interrogates the HLR. In this example the GMSC indicates 
its support for CAMEL. The GMSC receives back from the HLR the terminating CAMEL subscriber 
information. As a result the gsmSSF of the GMSC triggers a CAMEL activity toward the gsmSCF. 

6. Anchor decision 

The CAMEL service function denies the anchoring of the terminating call according to the operator policy. In 
this example the CAMEL service function is unable to allocate a new IMRN for this call i.e. insufficient IMRN. 

7. CAMEL CONTINUE (CAMEL service function to GMSC) 

The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL 
CONTINUE message. The CAMEL CONTINUE message contains no parameter. 

8. 9 and 10. Further interrogation with the HLR (GMSC to HLR) 

Following standard terminating call procedure for CAMEL subscribers, on the receipt of the CAMEL 
CONTINUE message, the GMSC interrogates the HLR again by including a parameter that indicates the 
suppression of CAMEL handling. On the receipt of the answer from the HLR, the GMSC resumes the processing 
and continues the call in the CS domain according to standard procedures. 



A.6 Signalling flows for CS domain to IM CN subsystem 
transfer 

A.6.1 Introduction 

The signalling flows for CS domain to IM CN subsystem transfer demonstrate how a VCC UE transfers the call from 
the CS domain to the IM CN subsystem. The following signalling flows are included: 

subclause A. 6. 2 shows the successful transfer for a call, currently in the CS domain, and which is transferred to 
the IM CN subsystem; and 

subclause A.6. 3 shows the case where a transfer request for a call, currently in the CS domain, cannot be 
complied with at the VCC application due to the failure to match the request with an anchored call for that user. 
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A. 6. 2 Signalling flows for CS domain to IIVI CN subsystem transfer 

Figure A.6.2-1 shows the signalling flows for a domain transfer of the access leg from the CS domain to the IM CN 
subsystem. This example assumes that the VCC user is currently registered in the IM CN subsystem. If the VCC user is 
not currently registered in the IM CN subsystem prior to determination of domain transfer, it is required that registration 
procedures are initiated before updating the access leg. 
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Figure A.6.2-1 : CS domain to IM CN subsystem transfer 

The details of the signalhng flows are as follows: 
1 . CS bearer (VCC UE to MGW) 

The call is ongoing in the CS domain. 



Remote end 
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2. IP bearer (MGW to remote end) 

IP bearer over which the voice call is transmitted toward to the remote end. 

3. Determination of domain transfer 

As a result of changes in radio conditions or availability of IM services via IPCAN, the VCC UE decides that the 
ongoing call in the CS domain will be transferred to the IM CN subsystem. 

4. SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) - see example in table A.6.2-4 

The VCC UE sends a SIP INVITE request to initiate session set up in the IM CN subsystem. The SIP INVITE 
request is sent from the VCC UE to the home S-CSCF (S-CSCF#1) via P-CSCF#1. The Request-URI header is 
set to the VDI (which is a PSI pointing at the DTF). 

Table A.6.2-4: SIP INVITE request (VCC UE to intermediate IM CN subsystem entities) 



INVITE sip : domain. xf erodtf 1 .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 .homel .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net; lr> 

P-Preferred-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-802 . lib; 

Privacy: none 

From: <tel : +l-212-5555-llll> ; tag=171828 

To : <sip : domain. xf erodtf 1 .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; port- 

c=8642; port-s=7531 

Contact: <sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxptime : 2 



5. SIP 100 (Trying) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities respond to the VCC UE with a SIP 100 (Trying) response. 
There is no VCC specific content to this response. 

6. Evaluation of filter criteria 

In this example, and by evaluation of the initial filter criteria, based on the VDI in the Request-URI header of the 
originating request for a registered VCC user, the S-CSCF routes the request to the DTF in the VCC application. 

7. SIP INVITE request (intermediate IM CN subsystem entities to DTF) - see example in table A.6-7 

The SIP INVITE request is forwarded from S-CSCF#1 in the home network to the VCC application which is at 
an AS. The AS acts as a routeing B2BUA. 
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Table A.6.2-7: SIP INVITE request (intermediate IM CN subsystem entities to VCC application) 



INVITE sip : domain. xf erodtf 1 .homel .net SIP/2.0 



Via 
Via 
Via 



SIP/2 .0/UDP scscfl. homel. net ;branch=z9hG4bK332b23 .1 



SIP/2 .0/UDP pcscfl.homel.net;branch=z9hG4bK24 0f34 .1 

SIP/2. 0/UDP [5555: : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .homel .net ; lr> 
Route : <sip : domain. xf erodtf 1 .homel .net> 
P-Asserted-Identity: <tel: +l-212-555-llll> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=type 

3homel .net ; 
P-Charging-Funtion-Address : CCf=[5555: :b99:c88:d77:e66] ; ccf=[5555: :a5 5:b44:c33:d22] ; 

ecf= [5555 : :lff :2ee:3dd:4cc] ; ecf= [5555 : : 6aa : 7bb : 8cc : 9dd] 
P-Access-Network-Info: IEEE-802 . 11b; 
Privacy: none 

From: <tel: +1-212- 5555- llll>;tag=171828 
To : <sip : domain. xf erodtf 1 .homel .net> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 
Supported: precondition, lOOrel 

Contact: <sip: [5555: : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



8. SIP relNVITE request (DTP to intermediate IM CN subsystem entities) - see example in table A.6.2-8 

The remote end is informed of the change in access leg from CS domain to IM CN subsystem by sending a SIP 
relNVITE request from the DTF to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.6.2-8: SIP relNVITE request (DTF to remote end via intermediate IIVI CN subsystem entities) 



INVITE <sip: [5555 : :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2 . 0/UDP domain. xferodtfl.homel. net ;branch=z9hG4bK3 32b2 3 .1 

Max-Forwards: 67 

Route: <sip : scscf .homel .net ; lr> 

P-Asserted- Identity: <tel : +1-212 -555- 1111> 

P-Access-Network-Info : IEEE-802 . 11b; 

Privacy: none 

From: < tel: +l-212-5555-llll>; tag=171828 

To: <sip :user2_publicl@home2 .net>; tag=1234 

Call -ID: dcl4bltlOb3teghmlk5 01444 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Contact : <sip : [7777 : : eee : ddd : ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



SIP relNVITE request (intermediate IM CN subsystem entities to remote end) - see example in 
table A.6.2-9 

The intermediate IM CN subsystem entities forwards the SIP relNVITE request to the remote end. 
Table A.6.2-9: SIP relNVITE request (intermediate IM CN subsystem entities to remote end) 



INVITE <sip: [5555: :eee:fff :aaa:bbb] :8805 SIP/2.0 

Via: SIP/2. 0/UDP icscfl . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
scscf 1. homel. net ;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
domain. xferodtfl .homel .net ;branch=z9hG4bK332b23 . 1 

Max-Forwards: 66 

P-Asserted- Identity: <tel:+l-212-555-llll> 

Privacy: none 

From: < tel: +l-212-5555-llll> ; tag=171828 

To: <sip :user2_publicl®home2 .net>; tag=1234 

Call -ID: dcl4bltl0b3teghmlk501444 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Contact : <sip:[7777::eee :ddd: ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



10. SIP 183 (Session Progress) response (remote end to intermediate IM CN subsystem entities) 
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The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

1 1 . SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to DTF 

The SIP endpoints complete SDP offer/answer procedures, including any reservation of bearer resource on the 
IP-CAN, and any exchange of alerting indication, in accordance with standard basic call procedures. VCC 
imposes no restriction on this operation. 

12. SIP 183 (Session Progress) response (VCC application to intermediate IM CN subsystem entities) 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

The 183 (Session Progress) response is forwarded to the VCC UE indicating the supported media at the VCC 
application so that the VCC UE can start to reserve resources for IP bearer setup. 

13. SIP 183 (Session Progress) response (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the VCC UE. 

14a - 14h.SIP PRACK request and SIP 200 (OK) response 

The SDP offer/answer exchange is completed. 

The SIP PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 

The remote end acknowledges receipt of the SIP PRACK request by sending a SIP 200 (OK) response. 

15. SIP 200 (OK) response (remote end to intermediate IM CN subsystem entities) 

The remote end acknowledges receipt of the SIP relNVITE request by sending a SIP 200 (OK) response to the 
intermediate IM CN subsystem entities. 

There is no VCC specific content to this response. 

16. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

17. SIP ACK request (DTF to intermediate IM CN subsystem entities) 

The SIP ACK request is sent from the DTF to the intermediate IM CN subsystem entities thus completing 
session update for the remote leg. 

There is no VCC specific content to this response. 

18. SIP ACK request (intermediate IM CN subsystem entities to remote end) 

The SIP ACK request is forwarded to the remote end via the intermediate IM CN subsystem entities thus 
completing session update for the remote leg. 

There is no VCC specific content to this response. 

19. SIP 200 (OK) response (DTF to intermediate IM CN subsystem entities) 

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 
(OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate 
domain transfer. This response is sent to the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 
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There is no VCC specific content to this response. 

20. SIP 200 (OK) response (intermediate IM CN subsystem entities to VCC UE) 

Final acknowledgement of receipt of the SIP INVITE request required to change the access leg. This SIP 200 
(OK) response indicates successful receipt and processing of the SIP INVITE request which was sent to initiate 
domain transfer. The intermediate IM CN subsystem entities forwarded this response to the VCC UE. 

There is no VCC specific content to this response. 

21. SIP ACK request (VCC UE to intermediate IM CN subsystem entities) 

The SIP ACK request is sent from the VCC UE to the intermediate IM CN subsystem entities thus completing 
session setup for the updated access leg. 

There is no VCC specific content to this request. 

22. SIP ACK request (intermediate IM CN subsystem entities to DTE) 

The SIP ACK request is forwarded by the intermediate IM CN subsystem entities to the DTF thus completing 
session setup for the updated access leg. 

There is no VCC specific content to this request. 

23. IP bearer 

IP bearer is established between VCC UE and remote end allowing voice call to continue via PS domain. 

24. SIP BYE request (DTF to intermediate IM CN subsystem entities) 

In order to release the access leg on the transferring-out access leg, the SIP BYE request is sent from the DTF, 
via the intermediate IM CN subsystem entities. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this request. 

25. SIP BYE request (intermediate IM CN subsystem entities to MGCF) 

The SIP BYE request is forwarded to the MGCF by the intermediate IM CN subsystem entities in order to 
initiate call release in the CS domain. 

There is no VCC specific content to this request. 

26. ISUP REL message (MGCF to VMSC) 

MGCF converts SIP BYE request to an ISUP REL message sent to the MSC#1 in the home CS network. REL 
Cause Value No. 16 (Normal clearing) is used. 

27. ISUP RLC message (VMSC to MGCF) 

The ISUP RLC message is sent by MSC#1 to the MGCF in response to the ISUP REL message. 

28. DISCONNECT message (VMSC to VCC UE) 

The DISCONNECT message from MSC#1 to the VCC UE includes Cause Value No. 16, thus initiating call 
clearing. 

29. RELEASE message (VCC UE to VMSC) 

The VCC UE responds to the DISCONNECT message by sending the RELEASE message to MSC#1 and enters 
the 'release request' status. 

30. RELEASE COMPLETE message (VMSC to VCC UE) 

MSC#1 sends the RELEASE COMPLETE message to the VCC UE thus releasing the MM connection. 
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31. SIP 200 (OK) response (MGCF to intermediate IM CN subsystem entities) 

This SIP 200 (OK) response is for the SIP BYE request and is sent to the intermediate IM CN subsystem entities 
from the MGCF. 

There is no VCC specific content to this response. 

32. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

This SIP 200 (OK) response is for the SIP BYE request and is forwarded to the DTF by the intermediate IM CN 
subsystem entities. 

There is no VCC specific content to this response. 

A. 6. 3 Signalling flows for unsuccessful CS domain to IIVI CN 
subsystem transfer 

Figure A.6.3-1 shows the signalling flows for the unsuccessful call transfer when transferring the call from the CS 
domain to the IM CN subsystem. The assumption is that VCC UE is not roaming and the MGCF is in the subscriber"s 
IM CN subsystem. It is also assumed that VCC UE is already registered to IM CN subsystem network. 
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Figure A.6.3-1 : Unsuccessful scenario when transferring call from CS to IM CN subsystem 

The details of the signalling flows are as follows: 
Step 1 through 7 are according to subclause A.6.2. 

8. DTF 

When DTF receives VDN indicating the domain transfer, it does not recognize the call leg associated with 
Calling Party Number CgPN or P-Asserted-Identity. 

9. SIP 480 (Temporarily Unavailable) response (DTF to intermediate IM CN subsystem entities) - see 

example in table A.6.3-9 
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The DTF sends a SIP 480 (Temporarily Unavailable) response to the intermediate IM CN subsystem entities. 

Table A.6.3-9: SIP 480 (Temporarily Unavailable) response (DTF to intermediate IM CN subsystem 

entities) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK35421G . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl.net : 7531;comp=sigcomp;branch=z9hG4bK24 0f 34 .1, SIP/2 . 0/UDP 
[5555: : aaa : bbb : ccc : ddd] ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net ; lr>, <sip:pcscf 1 . visitedl .net : 7531 ; Ir; comp=sigcomp> 
P- Asserted- Identity: < sip: domain. xferodtfl .homel .net> 
Privacy: none 

From: <sip : domain. xferodtfl .homel .net>; tag=12 34 
To: <tel:+l-212-555-llll>;tag=17182 8 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 12 7 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 
Content -Length: 



10. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to VCC UE) - see 
example in table A.6.3-10 

The error message is forwarded from intermediate IM CN subsystem entities to VCC UE according to standard 
procedures. 

Table A.6.3-10: SIP 480 (Temporarily Unavailable) response (intermediate IIVI CN subsystem entities 

to VCC UE) 



SIP/2.0 480 Temporarily Unavailable 

via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] ;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net : 7531 ; Ir; comp=sigcomp> 

P-Asserted-Identity : <sip:domain.xfer@stfl .homel .net > 

Privacy: none 

From: < sip : domain. xferodtfl .homel .net>; tag=12 34 

To: <tel:+l-212-555-llll>;tag=17182 8 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 

Content -Length: 



1 1 . VCC UE continues the call in CS domain. 



A.7 Signalling flows for IM CN subsystem to CS domain 
transfer 

A.7.1 Introduction 

The signalling flows for IM CN subsystem to CS domain transfer demonstrate how a VCC UE transfers the call from 
the IM CN subsystem to the CS domain. The following signalling flows are included: 

subclause A.7. 2 shows the successful transfer for a call, currently in the IM CN subsystem, and which is 
transferred to the CS domain; and 

subclause A.7. 3 shows the case where a transfer request for a call, currently in the IM CN subsystem, cannot be 
complied with at the VCC application due to the failure to match the request with an anchored call for that user. 

subclause A.7. 4 shows a domain transfer request from the IM CN subsystem to the CS domain using CAMEL, 
and which is rejected by the VCC application at the VMSC. 
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A. 7. 2 Signalling flows for IIVI CN subsystem to CS domain transfer 

Figure A.7.2-1 shows an example signalling flows for the domain transfer from the IM CN subsystem to the CS 
domain. The figure assumes that the UE is already registered with the CS domain prior to the decision to initiate 
transfer and that a call is anchored in the IM CN subsystem and the remote UE can be an IM UE. 

In this example, the communication between the CS domain and the DTP to resolve and process the request for domain 
transfer is supported through CAMEL. 
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Figure A.7.2-1 : IM CN subsystem to CS domain transfer 

The details of the signaUing flows are as follows: 

There is an ongoing IP bearer between the VCC UE and the remote end. 
1 . Determination of Domain Transfer to CS domain 
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VCC UE can make a decision for domain transfer. It can be triggered in case that the access technology of VCC 
UE is changed or the user preference or the operator policy is changed in consequence of the access technology 
change and so on. 

2. CC SETUP messages (VCC UE to MSC) 

The VCC UE sends the CS SETUP message towards MSC with the VDN as the called party number. 

NOTE 1 : VDN (VCC Domain Transfer Number) is not a routeable number towards the VCC application. It is an 
MSISDN used by the UE to request a domain transfer towards the VCC application. 

3. CAMEL INITIAL DP (VMSC to gsmSCF) 

On receipt of the SETUP message, the VMSC, in this example signalling flow, triggers a CAMEL activity which 
results in sending a CAMEL IDP message to the gsmSCF. The CAMEL IDP message contains at least: 

- the IMSI ie. 004412345678 

the calling party number ie. 12125551111; 

- the called party number that of the VDN, ie. 12415555555 

4. Handling of request for domain transfer 

The gsmSCF channels the request for domain transfer to the CAMEL service function which determines that the 
call needs to be rerouted to the IM CN subsystem. The CAMEL service function can optionally assist the CSAF 
with the allocation of an IMRN. 

NOTE 2: The gsmSCF and the CAMEL service function are connected through an unspecified interface left to 
vendor implementation. 

5. Interaction between the CAMEL service function and the CSAF 

The CAMEL service function can optionally assist the CSAF with the allocation of an IMRN. In this example, 
the CSAF accepts the request for domain transfer and assigns an IMRN, (IMRN = 12415553333). 

NOTE 3: The signalling to support communication between the the CAMEL service function and CSAF is not 
specified in this version of the specification. 

6. CAMEL CONNECT (gsmSCF to VMSC) 

The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL 
CONNECT message containing: 

- the IMRN = 12415553333 

7. CC CALL PROCEEDING message (VMSC to VCC UE) 

As VMSC can now proceed with the call, VMSC indicates the CALL PROCEEDING message back to the UE. 

8. ISUP lAM (VMSC to MGCF) 

The VMSC initiates the CS call towards the MGCF by sending the lAM with the called party number (i.e. 
IMRN) to indicate the VCC application. 

NOTE 4: The IMRN is a routeable MSISDN number towards the VCC application. 

9. MGCF allocates and configures MGW 

MGCF retrieves SDP from the ISUP lAM according to the 3GPP TS 29.163 [10]. The MGCF communicates 
with the IM-MGW to configure the media bearer. 

10. SIP INVITE request (MGCF to the intermediate IM CN subsystem entities) - see example in table A.7.2- 
10 

The MGCF initiates a SIP INVITE request towards the I-CSCF in the home IM CN subsystem of the originating 
VCC user with the PSI of the VCC application as the called party number. The tel-URI format of the IMRN as a 
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PSI (i.e. VCC application PSI) can be used for routeing towards the VCC application in the IM CN subsystem. I- 
CSCF routes the SIP INVITE request based on one of the standard procedures specified in "PSI based 
Application Server termination - direct/indirect/DNS routeing/service logic" procedures in 3GPP TS 23.228 [4]. 

The MGCF initiates a SIP INVITE request, containing an initial SDP. 3GPP TS 29.163 [10] specifies the 
principles of interworking between the 3GPP IM CN subsystem and ISUP based CS network, in order to support 
IM voice calls. 

Table A.7.2-10: SIP INVITE request (MGCF to the intermediate IM CN subsystem entities) 



INVITE tel: +1-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP mgcf 1 . homel . net ;branch=z9hG4bk731b87 

Max-Forwards: 70 

Route : <sip : icscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Access-Network-Info: IEEE-802 . lib; 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel: +l-241-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb :xxx;yyy 

s = - 

c=IN IP6 5555 :: aaa :bbb :xxx;yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: Contains the VCC application PSI, as a PSI based on the IMRN obtained from CS network 
signalling. The VCC application PSI is equivalent to the tel-URI format of the IMRN. 

From: Contains the calling party number to indicate the CS part of the caller, (e.g. Tel: +1-1-212-555- 

1111). 

To: Contains the VCC application PSI as the destination address. The actual destination address used 

for domain transfer from IM CN subsystem to CS domain is kept in the VCC application by the 
CS originating procedures described in subclause 7 and subclause A.4. 

1 1. SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) - see example in table A.7.2-11 

The IM CN subsystem entities route the SIP INVITE request towards the CSAF based on the CSAF PSI. 
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Table A.7.2-11 : SIP INVITE request (intermediate IM CN subsystem entities to the CSAF) 



INVITE tel: +1-241-555-3333 SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK764z87, 

SIP/2 . 0/UDP icscfl.homel.net;branch=z9hG4bK332b23 .1, 

SIP/2 .0/UDP mgcfl.homel.net;branch=z9hG4bk731b87 

Max-Forwards: 68 

Route: <sip : csaf 1 .homel .net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value= ' AyretyU0dm+601IrT5tAFrbHLso=023551024 ' ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +l-212-555-llll>; tag=171828 

To: <tel: +l-241-555-3333> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb :xxx,-yyy 

s = - 

c = IN IP6 5555 :: aaa :bbb :xxx,-yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



12. VCC application initiates domain transfer 

The CSAF and DTF in combination act as a routeing B2BUA, associating the incoming SIP INVITE with the 
ongoing session in the IM CN subsystem.. 

NOTE 5: During the initial IM CN subsystem origination procedure, the CSAF will keep the called party number 
and the calling party number for anchoring, domain transfer and so on. 

13. Interaction between CSAF and DTF 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

14. SIP relNVITE request (DTF to the intermediate IM CN subsystem entities) - see example in table A.7.2- 
14 

The DTF forwards the SIP relNVITE request back to the S-CSCF. 

The DTF modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of From, To, 
Cseq and Call-ID headers from one side of the B2BUA to the other. 
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Table A.7.2-14: SIP relNVITE request (VCC application to intermediate IM CN subsystem entities) 



INVITE sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP dtfl.homel.net;branch=z9hG4bK764z87, 

Max- Forwards : 6 7 

Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value= ' AyretyU0dm+601IrT5tAFrbHLso=023551024 ' ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To : <sip : user2_public2@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj5 90123 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact : < sip : [7777 : : eee :ddd:ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa : bbb :xxx;yyy 

s = - 

c = IN IP6 5555 :: aaa :bbb :xxx,-yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone-event 

a=maxpt ime : 2 



Request-URI: Contains the SIP-URI represented as an IP address indicating the called party UE, as retrieved 
from the VCC application. 

From: Contains the tel-URI indicating the remote VCC UE-A. A tag has same value in the existing 

dialog. 

To: Contains the SIP-URI of the called party UE. 

NOTE 6: If the called party UE is also the VCC UE, To header will be a tel-URI. 

Contact: Contains the SIP-URI indicating the VCC application. 

15. SIP relNVITE request (intermediate IM CN subsystem entities to remote UE) - see example in 
table A.7.2-15 

The S-CSCF routes the SIP relNVITE request towards the remote end. 
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Table A.7.2-12: SIP relNVITE request (VCC application to the remote UE through the intermediate IM 

CN subsystem entities) 



INVITE sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

dtfl.homel.net;branch=z9hG4bK7S4z87, 

Max-Forwards: 65 

Route : <sip : scscf 2 . home2 . net ; lr> 

P-Asserted-Identity: <tel: +l-212-555-llll> 

P-Charging-Vector : icid-value= ' AyretyU0dm+601IrT5tAFrbHLso=023551024 ' ; orig-ioi=homel .net 

Privacy: none 

From: <tel: +1-212- 555 -llll>;tag=171828 

To : <sip : user2_public2@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 590123 

Cseq: 127 INVITE 

Supported: lOOrel, precondition 

Contact : <sip : [7777 : : eee : ddd : ccc : aaa] > 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb :xxx;yyy 

s = - 

c=IN IP6 5555 :: aaa :bbb :xxx;yyy 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; mode-change-period=2 

a=rtpmap:96 telephone -event 

a=maxptime : 20 



16. SIP 200 (OK) response (Remote UE to the intermediate IM CN subsystem entities) 

The remote UE indicates the successful completion of the SIP relNVlTE request. 
There is no VCC specific content to this response. 

17. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTP) 
Indicate the successful completion of the SIP relNVITE request. 

There is no VCC specific content to this response. 

18. SIP ACK request (DTE to the intermediate IM CN subsystem entities) 
The DTP responds to the SIP 200 (OK) response with a SIP ACK request. 
There is no VCC specific content to this request. 

19. SIP ACK request (intermediate IM CN subsystem entities to remote UE) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the remote UE. 
There is no VCC specific content to this request. 

20. Interaction between DTE and CSAE 

Information is exchanged between the DTF and the CS AF. The nature of this signalling is outside the scope of 
this version of the specification. 

21. SIP 200 (OK) response (CSAE to the intermediate IM CN subsystem entities) 

The CSAE indicates the successful completion of the SIP INVITE request generated by the MGCF. 

The VCC application modifies the message in accordance with routeing B2BUA functionality, e.g. mapping of 
From, To, Cseq and Call-ID headers from one side of the B2BUA to the other. 

There is no VCC specific content to this response. 
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22. SIP 200 (OK) response (intermediate IM CN subsystem entities to MGCF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MGCF. 
There is no VCC specific content to this response. 

23. ISUP ANM (MGCF to VMSC) 

24. CC CONNECT message (VMSC to the CS part of UE-A) 

25. CC CONNECT ACK message (CS part of UE-A to the VMSC) 

26. SIP ACK request (MGCF to the intermediate IM CN subsystem entities) 

The MGCF generates a SIP ACK request in response to the SIP 200 (OK) response. 
There is no VCC specific content to this request. 

27. SIP ACK request (intermediate IM CN subsystem entities to CSAF) 

The intermediate IM CN subsystem entities forward the SIP ACK request to the CSAF. 
There is no VCC specific content to this request. 

28. SIP BYE request (DTF to the intermediate IM CN subsystem entities) 

On receiving the SIP 200 (OK) response (step 17), the DTF sends a BYE request to the IP multimedia side of the 
VCC UE via the intermediate IM CN subsystem entities. 

There is no VCC specific content to this request. 

29. SIP BYE request (intermediate IM CN subsystem entities to VCC UE) 

The intermediate IM CN subsystem entities forward the SIP BYE request to the VCC UE. 
There is no VCC specific content to this request. 

30. SIP 200 (OK) response (VCC UE to the intermediate IM CN subsystem entities) 

The IP multimedia part of the VCC UE responds to the SIP BYE request to indicate the successful completion of 
the domain transfer. 

There is no VCC specific content to this response. 

31. SIP 200 (OK) response (intermediate IM CN subsystem entities to DTF) 

The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the DTF. 
There is no VCC specific content to this response. 

A. 7. 3 Signalling flows for unsuccessful IIVI CN subsystem to CS 
domain transfer 

Figure A.7.3-1 shows the signalling flows for the unsuccessful call transfer when transferring the call from the IM CN 
subsystem to the CS domain. The assumption is that VCC UE is not roaming and the MGCF is in the subscriber"s IM 
CN subsystem. 
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Figure A.7.3-1 : unsuccessful call transfer when transferring call from IM CN subsystem to CS domain 

The details of the signalHng flows are as follows: 

Step 1 through 1 1 are according to subclause A. 7. 2. 

12. CSAF and DTF interaction 

Information is exchanged between the CSAF and the DTF. The nature of this signalling is outside the scope of 
this version of the specification. 

13. VCC application 

When the DTF receives IMRN indicating the domain transfer, it does not recognize the call leg associated with 
Calling Party Number CgPN or P-Asserted-Identity. 

14. SIP 480 (Temporarily Unavailable) response (DTF to intermediate IM CN subsystem entities) - see 
example in table A.7.3-14 

The DTF sends a SIP 480 (Temporarily Unavailable) response to the intermediate IM CN subsystem entities. 
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Table A.7.3-14: 480 (Temporarily Unavailable) response (DTF to intermediate IIUI CN subsystem 

entities) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK35421G . 1 , SIP/2. 0/UDP 

icscfl.homel.net;branch=z9hG4bK24 0f34 .1, SIP/2 . 0/UDP 

mgcf 1 .homel. net ;branch=z9hG4bk731b87 
Record- Route : <sip:scscfl .homel .net ; lr> 
P-Asserted- Identity: <tel : +l-212-555-llll> 
Privacy: none 

From: <sip:domain.xfer(adtfl .homel .net>, tag=1234 
To: <sip:mgcfl .homel .net>; tag=171828 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] > 
Content -Length: 



15. SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities to MGCF) - see 
example in table A.7.3-15 

The error message is forwarded from intermediate IM CN subsystem entities to MGCF according to standard 
procedures. 

Table A.7.3-15: SIP 480 (Temporarily Unavailable) response (intermediate IM CN subsystem entities 

to IVIGCF) 



SIP/2.0 480 Temporarily Unavailable 

Via: SIP/2. 0/UDP mgcf 1 .homel .net ;branch=z9hG4bk731b87 

Record- Route : <sip:scscfl .homel .net; lr> 

P-Asserted- Identity: <tel : +l-212-555-llll> 

Privacy: none 

From: <sip:domain.xfer@dtfl .homel .net>, tag=1234 

To: <sip:mgcfl .homel .net>; tag=171828 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 12 7 INVITE 

Contact : <sip: [5555 : : eee : f f f :ggg:hhh] ; > 

Content -Length: 



16. ISUP REL (MGCF to VMSC) 

Upon unsuccessful call setup, MGCF sends REL to VMSC. 

17. ISUP RLC (VMSC to MGCF) 

VMSC sends RLC to MGCF to confirm the REL. 

18. CC DISCONNECT message (VMSC to VCC UE) 
VMSC sends the DISCONNECT message to VCC UE. 

19. CC RELEASE message (VCC UE to VMSC) 

VCC UE acknowledges the DISCONNECT message by sending RELEASE message to VMSC. 

20. CC RELEASE COMPLETE message (VMSC to VCC UE) 

VMSC sends a RELEASE COMPLETE message to VCC UE to confirm the RELEASE message. 

21. VCC UE continues the call in IM CN subsystem 
VCC UE continues the call in IM CN subsystem. 

A. 7. 4 Signalling flows with domain transfer rejection at VMSC 
(using CAMEL) 

Figure A.7.4-1 shows the domain transfer attempt from the IM CN subsystem to the CS domain using CAMEL, and 
which is rejected by the VCC application at the VMSC. The domain transfer request is then abandoned, and the IMS 
call for which the domain transfer has been requested continues in the IM CN subsystem. 
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The decision to execute the request from the VCC UE for a domain transfer is subject to operator poHcy. 

NOTE: For domain transfer, the use of CAMEL in the context of VCC is optional. In this example the VMSC 
supports and uses CAMEL service logic. 
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Figure A.7.4-1 : Domain transfer rejection at VIVISC (using CAIVIEL) 

The details of the signalling flows are as follows: 

Steps 1, 2 and 3 are identical to the steps 1, 2 and 3 from the example in subclause A.7.2. 

4. Domain transfer decision 

The gsmSCF channels the request for domain transfer to the CAMEL service function which determines if the 
call needs to be routed to the IM CN subsystem. 

5. Interaction between CAMEL service function and CSAF 

The CAMEL service function can optionally assist the CSAF with the allocation of an IMRN. The CSAF rejects 
the domain transfer request from the VCC UE to the CS domain according to the operator policy. 

In this example the VDN is not a routeable number towards the IM CN subsystem and the VCC application 
failed to assign a new IMRN for this call i.e. insufficient IMRN. 

6. CAMEL RELEASE CALL (gsmSCF to VMSC) 
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The CAMEL service function causes the gsmSCF to respond to the CAMEL IDP message with a CAMEL 
RELEASE CALL message. The CAMEL RELEASE CALL message contains a release cause number #63 
'Service or option not available, unspecified'. 

7, 8 and 9. DISCONNECT, RELEASE and RELEASE COMPLETE (from and to the VCC UE) 

The VMSC release the call toward the VCC UE; steps 6 to 8 are identical to step 16 to 18 from subclause A.7.3. 
The cause used in the DISCONNECT is mapped from the CAMEL release cause received by the VMSC. 

There is no specific cause for VCC in the DISCONNECT. 

The call in the IM CN subsystem for which the domain transfer has been requested continues unchanged in the IM 
CN subsystem. 
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Annex B (informative): 
Example of filter criteria 

B.1 Introduction 

This annex provides some examples of filter criterion in the S-CSCF within the user profile of a specific public user 
identity. This filter criterion triggers S-CSCF actions following initial filter criteria evaluation of a SIP request thus 
resulting in orderly invocation of application servers. These examples are meant to illustrate the placement of the 
application server fulfilling the role of domain transfer function in a chain of application servers invoked to service an 
IM session. 

B.2 Example 1 - Service profile for UE originating for a 
VCC subscriber 

The example in table B.2-1 illustrates the case of iPC evaluations for originating sessions in the IM CN subsyetem 
initiated by a VCC subscriber who has also subscribed to the Connected Line Presentation (COLP) service. Only the 
example portion of iFC related to origination of an IM session is provided. Other portions of iPCs for evaluations of 
other SIP methods leading to actions on other application servers - for instance, for 3rd party registration - are not 
illustrated in this by example. 

For this example the illustration of the iFC is provided in an illustrative tabular form. 

For this example, the public user identity is userl_publicl@homel.net where homel.net is the URI of the home 
network. 

In this example, the first initial filter criteria triggers the S-CSCF to route the initial SIP INVITE request to the domain 
transfer function of the VSS AS addressed with the public service identity sip:dtfas. vcc.homel.net. When the SIP 
INVITE request is then returned from that VCC AS, the next initial filter criteria evaluation will cause the S-CSCF to 
route a SIP INVITE request to a call service application server for the user subscribed COLP service where that 
application server is addressed with the public service identity sipxolp. ssas.homel.net. 

Table B.2-1 : Service profile for UE originating for a VCC subscriber 

Service Profile (Public Identity user1_public1@home1.net) 

Initial Filter Criteria 

Priority 

Service Point Trigger 1 

Method: INVITE 

Session Case: Originating 

Application server: sip:dtfas.vcc.home1.net 

Initial Filter Criteria 

Priority 1 

Service Point Trigger 2 

Method: INVITE 

Session Case: Originating 

Application server: sip:colp. ssas.home1.net 
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B.3 Example 2 - Service profile for UE terminating for a 
VCC subscriber 

The example in table B.3-1 illustrates the case of iFC evaluations for a terminating session in the IM CN subsystem to a 
VCC subscriber who has also subscribed to OIP (Originating Identification Presentation) service. Only the example 
portion of iFC related to termination of an IM session is provided. Other portions of iPCs for evaluations of other SIP 
methods leading to actions on other application servers - for instance, for 3rd party registration - are not illustrated in 
this by example. 

The provided example iFC illustrates only one method of populating the iFCs whereby the domain transfer function and 
the domain selection function are treated by separate application servers. This example does not preclude alternate 
means of invoking the domain selection function, for instance, within the processing of the domain transfer function 
itself. 

Editor's note: Might it be useful to illustrate other examples of invoking the domain transfer and domain selection 
functions to reflect alternatives as provided in stage 2? That would however, require a separate annex of 
examples showing the use of filter criteria to invoke application servers in their required order. 

For this example the illustration of the iFC is provided in XML form. 

For this example, the terminating user has the pubUc user identity user2_public2@home2.net where the home2.net is 
the URI of the home network. 

In this example, this 1st initial Filter Criteria evaluation causes the S-CSCF to route a SIP INVITE request to an 
application server treating the user's subscribed call related service. In this example, the user's subscribed services are 
Call Diversion services and OIP service. This call service application server, in this example, is addressed with the 
public service identity sipxallserv. ssas.home2.net. 

When a SIP INVITE request is returns from the call services application server the next initial Filter Criteria evaluation 
will cause the S-CSCF to route a SIP INVITE request to an AS which performs the role of Domain Transfer Function of 
a VCC application addressed with the public service identity sip:dtfas. vcc.home2.net. After the anchor decision has 
been taken and the VCC AS with the domain transfer function role returns a SIP INVITE request, wherein the next iFC 
evaluation leads the S-CSCF to route a SIP INVITE request to an AS which performs the role of domain selection 
function addressed with the public service identity sipidsfas. vcc.home2.net. 
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Table B.3-1 : Service profile for UE terminating for a VCC subscriber 

< Service Prof ile> 

<PublicIdentity> 

<Identity> sip :user2_public2@home2 .net </Identity> 
</PublicIdentity> 
<InitialFilterCriteria> 

<Priority>0</Priority> 
<TriggerPoint> 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 
<Group>0</Group> 
<Method>INVITE</Method> 
</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > < /Group > 
<SessionCase>l</SessionCase> 

</SPT> 
< /TriggerPoint > 
<ApplicationServer> 

<ServerName>sip : callserv . ssas . home2 . net </ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
<InitialFilterCriteria> 

<Priority>10</Priority> 
<Tr igger Point > 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > < / Group > 
<Method>INVITE</Method> 

</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > < /Group > 
<SessionCase>l</SessionCase> 

</SPT> 
< /TriggerPoint > 
<ApplicationServer> 

<ServerName>sip :dtf as . vcc .home2 .net </ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
<InitialFilterCriteria> 

<Priority>10 0</Priority> 
<TriggerPoint> 

<ConditionTypeCNF>0</ConditionTypeCNF> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 
<Group>0</Group> 
<Method>INVITE</Method> 
</SPT> 
<SPT> 

<ConditionNegated>0</ConditionNegated> 

< Group > </ Group > 
<SessionCase>l</SessionCase> 

</SPT> 
< /TriggerPoint > 
<ApplicationServer> 

<ServerName>sip :dsf as . vcc .home2 .net </ServerName> 
<Def aultHandling>0</Def aultHandling> 
</ApplicationServer> 
</InitialFilterCriteria> 
</ServiceProf ile> 
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